Public bug reported: Updating base-files at point releases is pointless, misleading, and causes confusing and anxiety
Can we please stop updating base-files at point releases? Building new installer media, and calling it with a new .N number is good, and helps to differentiate what the initial state the machine roughly was, given that ultimately the serial # of the installer media is what matters. Updating base-files on the installed system => not so much. As it is an artificial line in the sand that doesn't change anything to the systems, that are continuously upgrading. The upgrade of base-files package, doesn't require to refresh snaps to latest revisions; install debs of latest versions; nor is anything else happening to force that (i.e. copying all packages from -updates to -security, like debian does). But it does cause confusion and anxiety among enterprise customers, who notice an update to base-files and a change of prompts, and suddenly demand to revert back from .2 release to .1. Which is understandable, since point releases in other operating systems have longer timespan, and are allowed to remain on an older substream for longer, and require admin actions to upgrade. Which is not the case with Ubuntu. Our interim releases, are actually closer to what windows/rhel call point releases. Since they are distinct, one can skip them, and they have a different time window. Our LTS is just a single stream of updates, which is continiously maintained, and thus it should always be recognized on the installed systems as "24.04 LTS". references: Windows 10 https://learn.microsoft.com/en- us/lifecycle/products/windows-10-home-and-pro note how windows 10 support multiple year/half releases, which are a track one can stay on for a long time, even as a new one is already out. Rhel point release timeframes https://access.redhat.com/support/policy/updates/errata#viii notice how every other point release is supported for up to 4 years, and is a track one can stay on for that period of time. Whereas Ubuntu LTS is a single track, that one cannot get off. There isn't a point release subtrack. ** Affects: base-files (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Updating base-files at point releases is pointless, misleading, and causes confusing and anxiety + Updating base-files at point releases is pointless, misleading, and causes confusion and anxiety -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/2009239 Title: Updating base-files at point releases is pointless, misleading, and causes confusion and anxiety Status in base-files package in Ubuntu: New Bug description: Updating base-files at point releases is pointless, misleading, and causes confusing and anxiety Can we please stop updating base-files at point releases? Building new installer media, and calling it with a new .N number is good, and helps to differentiate what the initial state the machine roughly was, given that ultimately the serial # of the installer media is what matters. Updating base-files on the installed system => not so much. As it is an artificial line in the sand that doesn't change anything to the systems, that are continuously upgrading. The upgrade of base-files package, doesn't require to refresh snaps to latest revisions; install debs of latest versions; nor is anything else happening to force that (i.e. copying all packages from -updates to -security, like debian does). But it does cause confusion and anxiety among enterprise customers, who notice an update to base-files and a change of prompts, and suddenly demand to revert back from .2 release to .1. Which is understandable, since point releases in other operating systems have longer timespan, and are allowed to remain on an older substream for longer, and require admin actions to upgrade. Which is not the case with Ubuntu. Our interim releases, are actually closer to what windows/rhel call point releases. Since they are distinct, one can skip them, and they have a different time window. Our LTS is just a single stream of updates, which is continiously maintained, and thus it should always be recognized on the installed systems as "24.04 LTS". references: Windows 10 https://learn.microsoft.com/en- us/lifecycle/products/windows-10-home-and-pro note how windows 10 support multiple year/half releases, which are a track one can stay on for a long time, even as a new one is already out. Rhel point release timeframes https://access.redhat.com/support/policy/updates/errata#viii notice how every other point release is supported for up to 4 years, and is a track one can stay on for that period of time. Whereas Ubuntu LTS is a single track, that one cannot get off. There isn't a point release subtrack. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2009239/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
