On 2019-05-07 09:34:26 +0200 (+0200), Marcin Juszkiewicz wrote: [...]
Found something interesting. And no idea who to blame...
We use http://tarballs.openstack.org/networking-infoblox/networking-infoblox-master... during development.
But master == 2.0.3dev97
So I checked on tarballs and on Pypi:
newton = 9.0.1 ocata = 10.0.1 pike = 11.0.1 queens = 12.0.1 rocky = 13.0.0 (tarballs only) stein is not present
Each of those releases were done from same code but changelog always says 2.0.2 -> current.release.0 -> current.release.update
Can not it be versioned in sane way?
2.0.2 -> 9.0.0 -> 10.0.0 -> 11.0.0 -> 12.0.0 -> 13.0.0 -> 13.x.ydevz?
The reason for this is that our present practice for service projects in OpenStack (which the x/networking-infoblox repository seems to partly follow) is to tag major releases after creating stable branches rather than before, and those tags therefore end up missing in the master branch history from which the master branch tarballs you're consuming are created. We used to have a process of merging the release tags back into the master branch history to solve this, but ceased a few years ago because it complicated calculating release notes across various branches. Instead official projects following this release model now receive an auto-proposed change to master as part of the cycle release process which sets a Sem-Ver commit message footer to increment the minor version past the rc1 tag (which is the stable branch point for them). Popular alternatives to this are either to tag an early prerelease on master soon after branching, or follow a different release process where branches are created when/after tagging rather than before (this is more typical of shared libraries in particular). One way in which x/networking-infoblox is not fully following the same release model as official services is that they don't seem to be tagging release candidates on master (or at all for that matter), which would partly mitigate this as you would instead see versions like 13.0.0.0rc2.dev3. Another way it's not fully following that model is, as you have observed, there's no stable/stein branch for it yet. -- Jeremy Stanley