Open Stack

Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +0000:
> Hey folks,
> 
> As we split out the repository per our unanimous vote several months ago, we have a choice to make (I think, assuming we are given latitude of  the release team who is in the cc list) as to which version to call kolla-ansible.
> 
> My personal preference is to completely retag our newly split repo with all old tags from kolla git revisions up to version 3.0.z.  The main rationale I can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could do that as well.
> 
> The reason the repository needs to be retagged in either case is to generate release artifacts (tarballs, pypi, etc).
> 
> Would also like feedback from the release team on what they think is a best practice here (we may be breaking new ground for the OpenStack release team, maybe not – is there prior art here?)
> 
> For a diagram (mostly for the release team) of the repository split check out:
> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
> 
> Thanks!
> -steve

When you say "split," I'm going to assume that you mean the
openstack/kolla repo has the full history but that openstack/kolla-ansible
only contains part of the files and their history.

Assuming the history is preserved in openstack/kolla, then I don't
think you want new tags. The way to reproduce the 1, 2, or 3 versions
is to check out the existing tag in openstack/kolla. Having similar
tags in openstack/kolla-ansible will be confusing about which is
the actual tag that produced the build artifacts that were shipped
with those version numbers.  New versions tagged on master in
openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).

Do you maintain stable branches? Are those being kept in openstack/kolla
or openstack/kolla-ansible?

Doug