grass
grass copied to clipboard
OSGeo
RFC: Version Numbering
This PR is a RFC for a new version numbering system. The main point is not making any distinction between even and odd version numbers. After 8.2.z, 8.3.0 would follow.
Notably, this RFC does not follow the current RFC procedure (if any), but creates a PR as suggested in the past as a possible improvement of the procedure.
Thanks @neteler for the comments. The minor versus micro is clearly an issue.
I identified some todos, but perhaps they are for next version of the RFC document:
- [x] discourage 82 and 820 versions, recommend 8.2 and 8.2.0
- [x] include recommendation for dates
- [x] specifically discourage linking name and version
- Example: don't use "GRASS GIS 8 includes foo and bar." when you simply mean "the most recent (current) version includes."
- Example bad: "The best version was GRASS GIS 7." Example good: "The best version of GRASS GIS was 7."
- "winGRASS 8.2.0/standalone" in release announcement of 8.2.0 does not make much sense. Obviously, the Windows binary is for the corresponding version.
- In short comments: G8 is unclear, when the version is important, using v8 is common practice.
- If version is really needed "The default database driver used by GRASS GIS 7 is SQLite." (as opposed to v6), say "The default database driver used by GRASS GIS is SQLite (since version 7)." so that the version number is always valid - the version of introduction stays the same and does not change.
- [x] consider clarifying that soft freeze is the branching (aka feature freeze) while code freeze is release RFC version (this came up during PSC meeting)
Perhaps discussion in #2575 is an opportunity to reflect again on what versioning and branching scheme we want to adopt. Perhaps what is now major.minor is just major, i.e., branch is major, not major.minor, and we drop micro.
The micro number has not been terribly relevant for some time. GRASS generally does not do bug fix releases and address version at the same time.
I do like using odd minor numbers for development, but I think we could release with major.minor and kill micro. I'm not sure just using major would provide enough granularity between stable and unstable releases.
On 10/20/2022 6:01 PM, Vaclav Petras wrote:
Perhaps discussion in #2575 https://github.com/OSGeo/grass/issues/2575 is an opportunity to reflect again on what versioning and branching scheme we want to adopt. Perhaps what is now major.minor is just major, i.e., branch is major, not major.minor, and we drop micro.
Message ID: @.***>
-- Best Regards, -Brad
I also implemented the minimal changes required by this RFC. Updating version numbers on main is now the same as on release branch, so the script which was capturing the intricacies of even-odd version distinction is now simpler.
As a consequence, the version on the main branch will no longer be in format X.Y.dev and X.Ydev, but always X.Y.Zdev like the release branches. In other words, with this RFC, there is no distinction between even and odd in terms of meaning and there is no distinction in numbering of different branches.
The main branch is simply the upcoming release and the (non-described) branching procedure updates only the version on main, while the branch keeps the original version from main. (Currently both need to be updated.)
The above is a example how this RFC simplifies the branching and release procedure which is an important aspect of this RFC.
The RFC suggests an additional change to the dev labeling (among other things), X.Y.Zdev should become X.Y.Z-dev because that's Semantic Versioning. However, I suggest to implement that separately, perhaps after branching or releasing 8.3.
Nice addition, +1. (by the way, here was my own definition of versioning, for the MapServer users : https://github.com/MapServer/MapServer/blob/main/SECURITY.md#version-numbering-explained )
As soon as the PSC adopts this RFC (voting is ongoing in https://lists.osgeo.org/pipermail/grass-psc/), the state will be changed to "Approved".
