So, we’re going with the “one bourbon, one scotch, and one beer” release methodology? 
1 Like
In my opinion, this an even finer proposal 
A new GNOME release may bring any number of user interface changes, or no changes. The new proposal makes the reality clear that every time you switch to a later version of GNOME, it might bring you some exciting and/or disruptive changes.
volunteer work is not fungible, which means we don’t get to tell people “no feature for this cycle”
This succinctly explains why GNOME can’t/shouldn’t make a more complicated promise than the above with regards to when we introduce changes and new features.
For some context, this is where Debian ended up. For ages there was a mix of 2.x, followed by some 3.x, and it was never clear when 4.0 should be released. We moved to simply incrementing the number by 1 each time there’s a main release, as otherwise people read into the number promises that simply weren’t true. I’d personally support the scheme of M.N above.
3 Likes
I don’t think we should put a GNOME 4.0 release out there. Because expectations.
1 Like
Should we skip to 5? Directly to 40?
I don’t think it’s a big deal because if we release GNOME 4 in September and then GNOME 5 in March, it should be very clear that GNOME versions are not related to GTK versions.
But I’m also totally fine with skipping ahead to GNOME 40. That makes sense too. If systemd can skip 200 versions, we can probably skip a few dozen.
I’m not a member of Gnome foundation/moderators so my opinion can be safely ignored. I only belongs to the commonality which use Gnome on daily basis.
I would expect/like that the versioning scheme to convey/imply two informations “when” was the software released and if there would be major features/breaking changes shipped.
I like the idea that the year of the release would be included in the versioning number.
I like skipping to 40 as well, avoids the confusion on why 4 was skipped.
Is that compatible with the versioning used in the majority of the package managers that ship GNOME? I’m pretty sure that alpha/beta/rc is going to be sorted after digits. If we need to preface them with ‘0’, then it’d be a shame to switch from one slightly opaque scheme to another one that’s slightly opaque.
“GNOME 40” sounds fine to me, though I think we don’t want to change the version midway through the 3.37 development cycle. We should release 3.38, and then move to the new version scheme at the beginning of what would be 3.39, so we can release 40.alpha1.
I don’t know; considering the wide-ranging bestiary of package managers, I think the responsibility for properly sorting alpha/beta/rc releases is really on downstreams.
Debian’s rules for upstream version numbers would cover the alpha/beta/rc versions, since they allow for dot-separated alphanumeric values.
The rules for Fedora would also cover alpha/beta/rc, as alpha sorts before beta, which sorts before rc.
I guess if downstream needs additional rules, they can also amend the package version.
In general, this proposal deals with user-facing version numbers—the version displayed in the Settings → About panel, and the About dialog for applications. Package versions are less interesting, since you can’t really install two versions of GNOME at the same time, so downstream packagers can conceivably keep calling their packages “gnome-something”.
3.38 would be the 40th release of GNOME, so we would go from 3.38 to 41, not from 3.38 to 40.
Sadly 40alpha sorts after 40. Here are examples of how the prerelease versioning has to work downstream. Certainly it becomes more complicated and annoying for downstreams.
3.38 would be the 40th release of GNOME, so we would go from 3.38 to 41, not from 3.38 to 40.
I think it’s better to go from 3.38 to 40, even if we have to pretend that one release never happened There’s a nice symmetry in the 40 release taking the place of 3.40.
This is the crux of the problem. The applications that would use this versioning are the ones which follow the GNOME versioning number, most of them being “core” applications, applications that are usually builtin to the OS from a “new install” perspective.
I very much think that those core applications shouldn’t have “user facing” version numbers to speak of, seeing as without digging into how they’re packaged, the value of the version number is pretty poor from the upstream developer’s point-of-view, for bug reporting.
All this to say that I don’t think that core applications should have “user-facing” version numbers, and that I’m all for changing the version number of GNOME to make it more of an event when we do have a release. The fractional progression makes it look like we’re not advancing very fast at all 
1 Like
That’s a “nice” coincidence, but if we skip to 40 I’d rather it happened because we went from 3.38 to 3.40, and dropped the 3.
Additionally, we already released 3.37.whatever, and changing now gets wonky.
I’m also against changing it so late in the cycle, we’ve already announced multiple unstable releases towards 3.38, then releasing 40beta1 out of the blue seems weird. (Plus I’d have less than a month to fix the release scripts or face the consequences).
Another way to look at it is GNOME 40 (a.k.a. 3.40) would be the 41st GNOME release, which has a 0-based index of 40
2 Likes
Yeah, if we don’t include the date, then 40 gets my vote as well.
It’s a clearer break with the old schema than 4 (which sounds a lot like “the successor to GNOME 3”), but also a nice continuation (just drop the “3.” prefix).
I’m sorry, I’m not sure what this is going to solve. If it’s to easily find when the release happened, then removing the leading “3” doesn’t help at all, you still need to count it, or find it elsewhere. As there is GNOME 2, the new major change in the UI was GNOME 3. Even that it happened around gtk3 is more or less a coincidence, I personally have it connected (possibly like many other users). Once you change the UI again you can call it GNOME 4. GNOME 40 looks odd (the same odd as Firefox 76.x.y, leading to 100 soon). But, well, my personal opinion.
I also do not understand whether it’s for the GNOME as a product, or also for the projects under the GNOME umbrella, which currently happen to follow version numbers proposed in Schedule - GNOME Wiki! . Some comment above mentions Help->About, but it’s not enough for me to understand it.
If it’s for the projects too, how is this going to work with version check macros in the code? I doubt 0alpha/alpha0 will work any good in the source code. Similarly the “Since:” notices in the developer comments. At least CMake declares project version as version number ( PROJECT_VERSION_PATCH — CMake 3.1.3 Documentation ), and it is worked with it as such in the code (like in the version check macros). What about pkg-config files? I’ve no idea how meson or autoconf/automake behaves here.
As an application developer, once switching from gtk3 to gtk4 I’d start versioning with leading 4. It makes sense to have the major version aligned with the gtk+ version in use for the application. The same happened when switching from gtk2 to gtk3. It helps with recognizing the things. Maybe not for everyone, of course.
The goal of the proposal is outlined in the first post in the topic: make the versioning scheme easier to understand for people using GNOME, and decouple it from major technological and design changes that are, at best, implementation details.
It’s for GNOME as a project, like I made clear at the very beginning, when I wrote:
The change in versioning is mostly meant for GNOME as a project. The only module that would need to reflect the new version is gnome-desktop , as that’s where the user visible version number is stored.
Libraries have their own versioning scheme, since that’s tied to technical issues like API and ABI; this won’t change. We’re still going to release GTK 4.0, not GTK 40.
Applications in the GNOME core SHOULD (in the RFC 2119 sense of the word) conform to the GNOME versioning scheme.
That’s what I’d like to avoid for GNOME as a project. The version of GTK is inconsequential, there, because the HIG, for instance, has much more of an impact than the version of GTK being used by a GNOME application. That’s one of the major goals of this proposal.
For GNOME applications, they are free to choose the versioning scheme they prefer—especially if they are not core applications. Core applications, on the other hand, SHOULD show the same version as the rest of GNOME, because we expect them to be installed, run, and updated within the same GNOME release.
1 Like
Aha, okay, it seems I started to read somewhere “in the middle”, where Michael gave a link to. Starting from the top would avoid some of my questions.
One thing left: when the libraries/applications change the version, and you said they SHOULD, it will affect the code, version check macros, build system and all those things. What I’m afraid the most is the version check macro, which expects pure numbers (aka 90), not texts (aka beta0), in the respective version fields.