Straw man proposal: Changing the GNOME versioning scheme

Community
,
43

So, it is time to draw up a formal proposal.

Summary

  • the existing versioning scheme—MAJOR.MINOR.MICRO—is confusing, especially now that we’ve stabilised around the “3” major version and we’ve constantly incremented the minor one
  • the even/odd split is unnecessary and does not communicate instability any more, given that very few users are even exposed to development releases of GNOME itself, and those that do, already know it

New versioning scheme

GNOME will publish two major versions per year; each version is going to be supported for no less than 12 months.

The version scheme is: YY.N.M

where:

  • YY are the last two digits of the year in the Gregorian calendar, e.g. 21 for 2021; the number is incremented only when the first release of the year is made
  • N is either 0 or 1, depending on the six months cycle
  • M is either one of:
    • one of alpha, beta, or rc, followed by a monotonically increasing number, for each development release
    • a monotonically number, starting from 0; the number is increased by 1 for every release

Examples

  • 21.0.alpha0: the first development release of the first six months cycle of GNOME for the year 2021; equivalent to 3.39.0 in the old versioning scheme
  • 22.1.beta2: the second beta release of the second six months cycle of GNOME for the year 2022; equivalent to 3.41.91, in the old versioning scheme
  • 23.1.0: the first stable release of the second six months cycle of GNOME for the year 2023; equivalent to 3.44.0, in the old versioning scheme
  • 24.0.9: the tenth stable release of the first six months cycle of GNOME for the year 2024; equivalent to 3.46.9 in the old versioning scheme

Recommendations

The GNOME core applications (as defined by the release team) are strongly encouraged to follow the same versioning scheme as the GNOME project.

The applications in the GNOME Circle group are free to follow their own versioning scheme, as well as cadence.

3 Likes