Hi all,
In consideration of the change (pending review) which adds the much
requested `--retry-failed` feature:
https://github.com/apache/buildstream/issues/1335
https://github.com/apache/buildstream/pull/1849
... I am reluctant to make a release including this feature addition
without bumping the minor version.
I think the "safely postponed" decision about versioning now has to be
addressed.
And as this is the first feature addition BuildStream 2.x release, it
presents an opportunity to break away from the versioning scheme
inherited from our origins in GNOME, which I have to reluctantly agree
is confusing and not what people expect from a semver versioning
scheme.
I.e. currently:
2.1.x = development snapshots leading up to a 2.2.0 release
But it would be nice if the next feature adding release was: 2.1.0
And that a dev snapshot leading up to 2.1.0 would be 2.1.0-dev0,
and -dev1, -dev2 etc ... in the case that we do want to release
dev snapshots, this follows the format generally used for python
prereleases.
Please let me know your thoughts on this change.
Cheers,
-Tristan
PS:
I've done a bit of analysis, and looks like the blockers we have to
actually updating the versioning scheme are few, here are the the
results of my research:
* runtime checks
A cursory reading of the code shows me there is no changes needed
here.
- The installed version is parsed by splitting on "." and only the
first 2 components (major/minor) are observed.
- One can depend on the next release version in advance when only
dev snapshots are available.
E.g. a project.conf of plugin's BST_MIN_VERSION can require "2.1.0"
when there is no such released version, if a "2.1.0-dev0" is
available.
* CI release workflows
The release workflow is triggered on the '*.*.*' glob match on pushed
tags, so this does not prevent the automated releases to occur on dev
snapshots.
This requires no changes as far as I can see, the "-devN" standard
for python will allow people to test development snapshots with
`pip install --pre BuildStream` automatically, as documented here:
https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#pre-release-versioning
* badges
doc/badges.py generates the badge svg/html snippet, which is
generated in CI and continuously updated at:
https://docs.buildstream.build/master/_static/release.svg
https://docs.buildstream.build/master/_static/release.html
https://docs.buildstream.build/master/_static/snapshot.svg
https://docs.buildstream.build/master/_static/snapshot.html
These are rendered inline in all published documentation and in
the README, so that no matter what documentation you are looking at,
you can be aware of what the latest stable/devel versions are.
This will need to be updated to differentiate stable/devel git tags
differently.
Since this only cares about the _latest_ versions, we need not care
about historical 1.x tags.
* documentation index website
At https://docs.buildstream.build/, we generate the index of per
release documentation.
The generate_pages.py script which generates this will need to be
updated so that:
- We continue to ignore odd numbered minor points for the bst1 docs
- We stop ignoring odd numbered minor points for the bst2 docs
