updatenotification "v2" - iterating on the existing overview page (web) and new update notification controls [WIP]

[joshtrichards]

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 updatenotification app 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).
  • 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
  • Approach to releases and upgrades (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.

[joshtrichards]

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:
  • Maintenance releases for the currently installed major.
  • When the currently installed major is <{ 90 } days from end-of-life.
  • 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)

[joshtrichards]

Needs:

• Planned eol date for an installed branch
  • needs to be somewhere that can be polled or included in the release itself
  • easiest approach seems to be to add it as an additional field provided by the updater_server (which we then store at update time with the other update related values already tracked as standard app values within an installation)
• Planned release date for next maintenance release
  • needs to be somewhere that can be polled or included in the release itself
  • easiest approach seems to be to add it as an additional field provided by the updater_server (which we then store at update time with the other update related values already tracked as standard app values within an installation)
  • either needs to be the actual planned release date or calculated from the release date of the installed version
    • we can - for now - probably just calculate +30 days from the release date of the existing version since it's just meant be a rough estimate and will vary anyhow (i.e. sometimes we release maintenance releases sooner for... reasons).
    • I guess it might be possible to pull this from github as an alternative, but since we already have the updater_server seems cleaner to do it there

---

• Both of the above are covered by eol dates nextcloud-releases/updater_server#1050
  • feat(config): introduce configuration builder nextcloud-releases/updater_server#1053 may help with this as well
• For projecting the next maintenance release,
  • Add the date a release is published somewhere accessible e.g.
    • add published YYYY-MM-DD date field to updater_server response for every release

---

Decide how to handle transition:

• existing installations will not have this data until their next update cycle