2:48 p.m.
We have changed our merge numbering model.
We used to have very long cycles with weekly merges labeled -devNN, then a several week RC
(that never actually seemed to be tested by people, and was dropped), followed by a major
release, and then point releases on top of that. New features were held for the next major
release.
Some people were frustrated at the delay in availability of new features. Lining up
releases with the needs of the enterprise products that pay our salaries was also
challenging, sometimes resulting in products releasing based on a -devNN merge.
There was also significant effort to try and support a "stable" release, with
additional minor releases following a fork to allow -devNN merges for the next major
release.
It's also worth noting that a Ganesha major release never came with any specific
testing. Upstream testing is limited to the CI that runs on every path, a CI that is run
every week, and my running pynfs before pushing merges. We don't have the resources
for anything more than this upstream. As a maintainer trying to also do work to earn my
paycheck, I am very appreciative that we have a weekly CI run that does more testing than
I can manage the time for.
So we decided to simplify and just have a single release stream. Rather than just
numbering every build, we still use major/minor, bumping the major version if a feature of
some significance drops, and bumping minor version for merges that just contain bug fixes
and minimal features. One way to think of it is Ganesha releases are now more Agile.
I would also add that the number of active developers has increased within the past few
years and this is resulting in a faster pace of significant features, and even scope of
those features.
I was trying to bundle most of the features that are dropping in a single merge, however
it became clear that delaying several features to wait for others was becoming too much,
so yes, we have had the major version jump rapidly over the past few weeks. As the last
few features that are currently on deck get merged though, the cadence will settle down.
We don't expect enterprise products and Linux distributions to pick up every release,
rather, they should grab a release near their feature cutoff date or whatever works for
them.
Thanks
Frank Filz
-----Original Message-----
From: Robert Sworder [mailto:robert@thatcode.com]
Sent: Monday, July 20, 2026 7:21 AM
To: devel(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Devel] Re: Announce Push of V12.0
Hi!
Firstly, thanks for all your work on NFS Ganesha, and sorry if this has been answered
elsewhere that I couldn't find.
Is it possible to have some clarity on how you choose the next release version? I'm
wondering because there's been a sudden change in the velocity of major releases, and
I'm wondering what level of changes these really correspond to. The rapid increase in
version numbers is causing some concern, so understanding what's happened to trigger
it will help us organise a suitable level of testing!
To give examples:
V4.0->V5.0 - Dec 2021->Apr 2023 - 16 months
V5.0->V6.0 - Apr 2021->Aug 2024 - 16 months
V6.0->V7.0 - Aug 2024->Jul 2025 - 11 months
V7.0->V8.0 - Jul 2025->Oct 2025 - 3 months
V8.0->V9.0 - Oct 2025->Oct 2025 - 0 months
V9.0->V10.0 - Oct 2025->Jun 2026 - 8 months
V10.0->V12.0 (with V11.0 in the middle!) - Jun 2026-Jul 2026 - 1 month.
Is this due to an increased pace of development? Or specific high risk/churn features that
have gone in? Or something else? What makes V10/11/12 new major releases rather than new
minor releases?
Thanks for your time,
Robert
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org