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@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org