On Thu, 18 Aug 2022 at 21:52, Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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@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
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@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
