Versioning of Budgie Desktop

[fossfreedom]

The discussion here is about the rather dry subject of versioning. Something myself I cannot really get too excited about but I know the wider world does in terms of "seeing progress", supportability etc..

The current release tarball cannot be built on the latest rolling releases nor on the latest fixed released distros.
This is a pain in the whatsit for maintainers who have to cherry-pick patches to make things build.

From a supportability point of view "10.5.3" doesn't really mean very much - because the project has no idea what is the delta between the release tarball and the current state of play the distro is in.

In the past the versioning schema that budgie desktop has used is rather odd - the a.b.C - the C number is denoting a formal major release when a lot of projects just use it for bug fixes.

The a.B.c - B is usually for a lot of projects for describing new capability / ABI/ API type breaks.

The A.b.c - A is usually for a lot of projects for a really significant change - I would count budgie 11 is that category.

The purpose of this discussion is to get agreement for the B & C versioning. Whilst we can all agree the the regular 6 monthly uplift of GNOME stuff breaks an inordinate amount of stuff we have to end up fixing in budgie - we have used that 6 monthly uplift informally to use the "last 2 GNOME release" strategy of our support. Fair enough. When we do, we clean up/remove the older releases. This to me is basically a B change and we should reflect that. That means for the 10.x series we should consider version uplifts with GNOME uplifts. Obviously for budgie 11 no need to worry about other project issues other than EFL.

For the C change we could (for a suggestion) work on a quarterly / as needed basis.
I would include potential resolution of crashes and translations as worthy of a C change. The advantage here is to allow distro maintainers to quickly update to the recommended baseline ASAP - this makes it easier for this project to identify the real distro level that the project is using rather than the "its 10.5.3 + a random set of patches".

This actually doesn't help Debian / Ubuntu because when they are in stable release mode, the C change is only allowed if there is an accompanying set of source code tests that is run to confirm all is well. Budgie 10.x series doesnt have source control tests. So Debian & Ubuntu has to live with "10.5.3 + a random selection of patches" strategy.

My suggestion here is to approach budgie 11 with that source control testing strategy in mind whilst developing rather than as an after thought.

[JoshStrobl]

Thanks for opening this discussion. I agree that it should largely follow SEMVER 2.0.0 and future releases should probably go the route of:

• 10.6
• 10.6.1 when we feel there is a good set of fixes to distribute
• 10.7
• etc...

I don't think it is necessary for it to be being quarterly or a specific schedule, beyond getting a MINOR version out around the same time GNOME releases a new major and we need to update deps. Like 10.6 as it stands could be released now-ish (next couple weeks, alongside tagging budgie-desktop-view) just to have something out for 41. 10.7 can be in or around March, at latest, for GNOME 42, and so on.

Other than that, I think we can tag new MINOR versions and PATCH versions at our leisure. If we have a good batch of bug fixes, or a considerable amount of translation improvements, then we can trivially release a new PATCH version.

The advantage here is to allow distro maintainers to quickly update to the recommended baseline ASAP - this makes it easier for this project to identify the real distro level that the project is using rather than the "its 10.5.3 + a random set of patches".

Yep, in complete agreement.

the C change is only allowed if there is an accompanying set of source code tests that is run to confirm all is well. Budgie 10.x series doesnt have source control tests.

Bit of a silly requirement on their part 🤷

My suggestion here is to approach budgie 11 with that source control testing strategy in mind whilst developing rather than as an after thought.

I can see that being useful for libraries we develop but would love some insight on the preferred mechanism for testing graphical applications in the Debian world. Obviously GNOME-specific solutions won't translate to 11.