-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V15+? #293
Comments
Yeah - Once all the other things are upgraded 😟 - the 'core' migrations in uSync are lightweight at the moment, they are, someone changed blocks, or the RTE format has shifted slightly, I think there is still going to be a place for, moving grid to block grid or nuPickers to Contentment, so probibly this does have a future in releases. I would like to move this to the new platform, but to be honest at the moment, i would say the stability isn't there in the Umbraco client libraries, if this were targeted to v15 it would certainly break for v16, and then it would need another upgrade. That would then mean the level of maintenance would increase because this would need updating all the time, along side all the other things that need upgrading all the time. 😵 but, i think this is a must to get working for a v17 LTS release, so maybe targeting a release for v16 might make sense, (and by extension doing some work now to get it working on v15 wouldn't hurt in that aim.
It's a hotch-potch of code, its being contributed to by many many people with loads of 'hacks' so might need to refactor and tiding up. but if you want to take a look at any of it, by all means 😉 . |
I already started looking into it, but wasn't sure how to touch backoffice: Also I just wanted get familar with v15 codebase to be ready for v17 as I wouldn't use umbraco before 17.5 on new codebase lol |
I think, i pre-split things to make this eaier (in theory!) so the uSync.Migrations.Client project is the bit that would change for v15, in core uSync (and other packages) i have ended up having a diffrent client project for v13, and v14, and then you can include / exclude the client from the package dependingon the version. e.g in uSync. there is uSync.Backoffice.Assets, for v13 and uSync.BackOffice.Client for v15 (uSync seperates out the mangagent api into its own project too, but i don't think that is nessercery). So for v15 i would say a new project uSync.Migrations.NuClient ? or something, which targets v15 and contains the typescript files and the ApiControllers that will be the clients way into the back office. maintance manager is probibly a small example of what that client library can look like but diving into v14+ client libraries from scratch, 🤯 - its one of those things! |
@KevinJump I am familar with Vite, is more i want follow your way of doing as migrations are still your package :) I was asking more about reusting bits from npm of usync as if I remember correctly you reuse some bits in migrations in v13. |
Hey @KevinJump I am just wondering if there is point of updating this to v15, as i noticed you done some bits of migrations in usync and usync complete, if you planning updating this repo as well, I am happy to help with updating :)
The text was updated successfully, but these errors were encountered: