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
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
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
