Open Stack

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.tar.gz
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190507/b85c4f4b/attachment.sig>