Adds some general information about considerations for upgrades #7288
Conversation
|
Thanks for the PR @AndyButland ! While I think this is very valuable information, I'm concerned about adding it to an already very long article. That's my two cents. |
|
I see the point @sofietoft but what I was aiming for here was a general introduction to upgrades that is worth reading before you dive into the detail. As I do see some confusion about what we are talking about when we discuss these. So rather than hiding it in an expandable section, if you feel this page is too long, I think I'd prefer moving what I've added to a new page and placing it before the existing one in the summary. Then you can dive straight into the detail if you know the background, but if not, you'll hopefully see this new content first. Let's get @BoletteKern's view too though - as this I've put this together following a request she had having had some feedback on this topic. |
|
Yes, splitting up is also a good idea! We can always highlight the page with a link from the article, as something we recommend going through before initiating the upgrade process. We'll wait for Bolette, before we make any changes for now 🙏 |
There was a problem hiding this comment.
Hi Andy!!
This gives a great overview of what users don't need to worry, and what they should consider and test when upgrading. I only have small suggestions, and mainly about lilnking to more information.
I think the "What is involved in an upgrade" and "Before you upgrade" should be in one article, and "upgrade to a new major", "upgrade to a new minor" and "Run an unattended upgrade" as subarticles.
There was a problem hiding this comment.
Can we refer to where this communication is made, e.g., Release Notes and Announcements on GitHub, and Release Blog Post on umbraco.com?
There was a problem hiding this comment.
I do have that actually - in the sentence:
Umbraco communicates about the breaking changes in release blog posts and on the documented version specific upgrade details.
There was a problem hiding this comment.
I think we use "obselete" more than we use "legacy". Perhaps rewrite to:
They are only removed in major versions and with plenty of notice under announcements on the Umbraco repository on GitHub. When a feature is deprecated, a minor version is released with the deprecation, and the feature is deprecated for the next major release.
There was a problem hiding this comment.
Have rewritten this slightly - mainly to add reference to the announcements repository, which is good to call out I agree. On the wording though, I think legacy is right here when we talk about features, and it's the word we used when retiring "Nested Content" for example. Obsolete is more used for code APIs.
There was a problem hiding this comment.
All good, if "legacy" is the right wording. I just noticed we use "deprecation" on this page https://umbraco.com/products/knowledge-center/versioning-and-release-cadence/
I've split the article now as per this suggestions. Please see what you both think. |
|
Changes looks good. I think it makes sense to split it up even further like Bolette suggest. So, having the different types of upgrades in each their own article. One for Major upgrades, one for minor and finally, one for running upgrades unattended. I also think we should mentioned about the version specific guides and notes, on the new landing page for this section. I'll make these addition after we've merged this PR. |
📋 Description
Adds some general information about considerations for upgrades
✅ Contributor Checklist
I've followed the Umbraco Documentation Style Guide and can confirm that:
Product & Version (if relevant)
Umbraco CMS
Deadline (if relevant)
Any time. Once approved can be copied to at least the Umbraco 13 pages, so we have it on the last LTS.