joshtrichards
commented
4 months ago Update
Your Nextcloud is up-to-date.
You are currently running major release v29.
- v29 will receive maintenance updates (bug/security fixes) through 2025-04.
- The next maintenance release is projected to be published on 2024-05-23.
However, an optional new major release (v30) is available.
- You do not need to upgrade to v30 until v29 reaches end-of-life in 2025-04.
- You can upgrade today to gain access to new features and optimizations sooner.
- WARNING: Some of your active apps are currently incompatible with v30.
- NOTE: Please review Critical Changes prior to upgrading to avoid service disruptions.
You are on the stable release channel (Server/Apps).
- The following groups are automatically notified about new releases: { admin }
- They will only be notified about the following types of releases/situations:
- [x] Maintenance releases for the currently installed major.
- [x] When the currently installed major is <{
90} days from end-of-life. - [x] New major releases.
How to Upgrade | Changelog | Release Schedule | Community Support | Enterprise Support
Last checked: 2024-05-17 04:08:55 UTC (next check: 2024-05-18 04:08:55 UTC)
This is a conceptual overview of a possible iteration on the Update status overview page (web) along with some new admin controlled notification handling for new releases based on their preferences.
This functionality is largely handled via the
updatenotificationapp today.This is a summary of some brainstorming I've been doing. It's obviously not set in stone.
early brainstorming notes
--- First of all, here are two examples of the existing screen in our current releases which we're all likely fairly familiar with:    There have been a few minor modifications, but it's largely been about the same for awhile. --- Challenges: - multiple simultaneously supported major versions in our `stable` channel - different in preferences across environments about how aggressive/conservative to be about deploying new majors - confusion about what it means when we say "You're up-to-date" - Running one of the supported major releases? - Running the latest major release? - Running the latest maintenance update for the currently in-service major release? - etc. - we make admins search around to check end-of-life dates as well as see if the next major being offered to them means their currently in-use version has reached end-of-life or not; sometimes there is added confusion whenever we publish a new major since it gets offered and a new cycle of "update stress, uncertainty, excitement, and work" arises for admins - e.g. - does the admin need to update to this major ASAP to continue to receive bug/security fixes? - when *must* the admin start preparing to update to the next major version? - i.e. when does the currently in-service major release reach end-of-life (i.e. when *must* they prepare for a major version bump)? - when can the admin expect the next maintenance release for their currently in-service major release? - can the admin be confident that the information provided on the Update screen is *itself* up-to-date and accurate - how can the admin make their own informed decision about how/when to deploy new majors? - and: - "what the heck is a major release?" - "what the heck is a maintenance release?" - "what the heck is a release channel?" - "doesn't stable mean *stable*?" - "what do I need to know before I deploy the newly offered major?" - "how can I stay on this major for awhile, but still be informed about every *relevant* maintenance release as well as get a heads when I need to start thinking about a major bump again?" - packagers/installation method differences that impact Update methods - i.e. - unique instructions - unique update processes - need to prevent some methods that are incompatible with the packaging method - e.g. - Archive - Snap - AIO Docker - Micro-services Docker - it'd also be kind of cool if packages could even integrate here somehow (but this one is likely more for a future follow-up) - some update modes more/less reliable than others (e.g. web timeouts/missed error messages versus cli mode) - this is more likely more for a future follow-up or some other parallel work in the Updater itself --- Proposed (Update overview screen content) Notes: - most of the info here is real, but some has been faked for demonstration purposes - will shrink some as further editing is done - there will be variations on the below just as there is today such as when the in-use major release is end-of-life # Update Your Nextcloud is up-to-date. However, an optional new **major** release (v30) is available. ## Overview * You are currently running **major** release v29. - The latest maintenance release (v29.0.0) is installed (containing all published bug and security fixes). - This major release is currently known as the *previous latest* major release and will continue to receive maintenance updates and support through 2025-04. - This means this code base is not the absolute latest in terms of features and functionality, but is fairly mature. It offers features and functionality added in the past 4-12 months as well as access to regularly published maintenance releases for any critical bug/security fixes (for the next 11 months). - The next maintenance release for this major (v29.0.1) is projected to be published on 2024-05-23. * The optional new **major** release (v30): - **Some of your apps are currently incompatible with v30.** - You do not need to upgrade to v30 for another 11 months, but you may wish to upgrade earlier for new functionality and features. * You are currently on the `stable` release channel (for both Server and Apps). - You are currently receiving notifications for *all* supported majors and maintenance releases in the `stable` release channel. - You may opt instead to only be notified about *latest* majors, *previous latest* (still supported) majors, or *last supported* majors (and their corresponding maintenance releases) until your current release is <90 days from end-of-life. - The following groups get notified about these new releases: { admin } * This information is accurate as of (and Updates were last checked for automatically) at 2024-05-17 04:08:55 UTC. ## Reminders * Downgrading is *not* supported. * Always keep up-to-date backups of your Nextcloud files, configuration files, and the Nextcloud database. * New **maintenance** releases: - Address security vulnerabilities as well as critical or annoying bugs in all still supported major releases. - Should be installed as soon as possible. * New major releases in the `stable` channel: - Introduce new features and functionality - May introduce breaking changes that require adaption of your configurations and environment both **prior to** installation and after (see *Critical Changes* in the [Release Notes](https://docs.nextcloud.com/server/latest/admin_manual/release_notes/index.html)). - The *highest* numbered majors offer the latest features. - The *lowest* numbered majors (that have not reached end-of-life) offer the most time in the field. - Are rolled out in stages and not offered to 100% of Servers until generally the second maintenance release (x.y.2) is published * Nextcloud's: - [Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) - Approach to [releases and upgrades](https://docs.nextcloud.com/server/latest/admin_manual/release_schedule.html) (bug fixes, security vulnerability patching, back porting, major releases, maintenance releases, development cadence, and update channels) --- Implementation gaps: - some dates need to be accessible in some more useful form than on the current wiki page (e.g. distributed as json, via an API from the updater_server, etc.) - end-of-life dates - projected release dates for majors - projected release dates for maintenance releases - a bunch of logic to make the presentation sane / readable based on dates, version numbers, etc. - some of this exists today / some will need to be adapted - some doesn't exist since there's no counterpart today --- Side note: In theory *some* bits of should also flow through to the Updater itself, primarily so that when it's ran in CLI mode it can handle things in a consistent (or at least not wholly inconsistent) manner (more on that in a follow-on).See follow-on comments for current iteration.