You can think of future major-releases of Umbraco as far less obstructive than previous major-versions have been, but potentially a little more obstructive than previous minors. It is our intention that an upgrade-path will be easy and available for all.
Deprecating things
Along with this change, we will also state our formal deprecation policy. Going forward when we need to remove from the public API, we will release a minor version with the deprecation in it, and keep it around for the next major as well. (So announced deprecation in 3.2.0 means it may no longer be available in 5.0.0).
This is a big change, and you probably have unanswered questions. Let us try to answer some of them beneath – if you still have questions, please reach out on product@umbraco.com or to me directly on Twitter.
Will you start over from 1.0.0 then?
Yes. The .NET Core release of Umbraco is going to be a new package and startover from 1.x. Current alpha is called 0.5.0 for the same reason. Until then, we will stay on 8.x and release minors every 6 weeks, and patches when necessary.
Updated: No, after community feedback and careful consideration we've decided to continue from the current version (v8). So the next major release will be Umbraco 9.
What if I don’t want to update all the majors
Every 2 years, we intend to mark a major version as Long Term Support. This means it will continue to receive patches for 27 months after its release. Hence, there will be a 3-month overlap after the next LTS is released. All other major-version only receive patches for 9 months after release.
How hard will major upgrades be?
We still aim at making as few breaking changes as possible, and to provide migrations when possible. There will be a migration path from 8.x.x to the .Net core version (new NuGet package starting from 1.0.0), but because of the size and scope of that migration, you can expect that to be a bigger task. Future migrations will not be that big.
What is and is not considered a breaking change
We will follow SemVer 2.0. This means that incompatible changes to the “public API” of Umbraco is considered breaking and requires a new major version. Internal and dependency-changes, are not considered breaking and do not require a new major version. What exactly the “public api” is will be determined before the final release.
What about the frontend
We will keep the existing definition of what a breaking change is for the backoffice for the time being. We want to eventually change that also. Look forward to talking about the future of backoffice at a later time.