On Thu, 18 Aug 2022 at 21:52, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
> Stephen Smoogen wrote: > > I should have been clearer. I was talking about the changes between > > XP->7->8->8.1->10->11 versus 10.<date_1> -> 10.<date_2>. I was thinking > of > > it more since for the most part they used pretty much the same compiler > > for all of 10 versus new compiler and major library changes every six > > months > > That is a very developer-centric view though. End users will usually not This is a developer centric mailing list and you have in the past been quite likely to point out in very clear terms when I am not being developer centric here :). > > care about what compiler the operating system was compiled with, all the > more on Windows, which does not even ship with a compiler (so those who do > actually need to compile code can select their compiler version more or > less > independently of the operating system version). > > What they will notice though is when the Windows desktop shell (the > Windows > equivalent of KDE Plasma or GNOME Shell) gets a major update which makes > it > look&feel different, and I know from Windows users' complaints that that > has > happened repeatedly in Windows 10 point releases. Start Menu, Control > Panel, > etc. have all had significant look&feel changes at least once. > > And as you point out yourself, those updates are also not always without > issues. E.g., another frequent complaint is that device configuration is > reset during upgrades, e.g., that it simply forgets printers that are not > plugged in while upgrading (and always plugging in all hardware is not > possible on a notebook that travels between different locations). > > So I would really compare those Windows point releases with Fedora > releases. > The schedule is basically the same and the risk is also about the same. > (Though one difference is that Windows ships a lot less software, so you > can Yes they have a very much 'core'/'extras' viewpoint on their software. The 'core' parts are compiled with their same inhouse compilers for about '2 year' runs and then moved to the next level. [This is why there are 6 month updates and about an 18->24 month mega update in the 10 cycle.] They are now moving away from that and will just move to 11 and then 18 months to 2 years later to 12, etc according to their announced schedule. The extras are becoming more like 'flatpaks/scls' in that they are a bundled universe with their own path settings, libraries etc to make things work. Because it is a 'core'/'extras' strategy, I didn't see it as something we would emulate. > > have fewer issues with software getting upgraded as part of the operating > system upgrade there. Though that can also result in the application > stopping to work after the operating system upgrade, at least until you > manually upgrade the application as well.) > > I wonder whether we should simply switch Fedora releases to a different > numbering scheme more like RHEL or Windows. (Keep in mind that my > suggestion > would be only a pure renumbering, there would be no changes whatsoever to > the schedule (including EOL dates) or the nature of the releases.) So we > would by default just release the next Fedora as 37.1, then 37.2, etc. > Only > if some comittee (probably FESCo) decides that a release has enough major > changes to warrant a new major version (e.g., Fedora 9 with KDE/Plasma 4, > GCC 4, etc., or Fedora 15 with GNOME 3), then it moves to 38.0. This can > be > decided shortly before the release, after having the final list of > accepted > and not reverted changes. After all, Linus also decided on a fairly short > notice to renumber the kernel from Linux 5.20 to Linux 6.0, without even > any > reason for the bump other than "the second number is getting too large", > so > my proposal would work similarly, but less arbitrarily and more in the > spirit of semantic versioning. > > Kevin Kofler > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
