[openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

Doug Hellmann doug at doughellmann.com
Fri Nov 11 14:43:47 UTC 2016


Excerpts from Steven Dake (stdake)'s message of 2016-11-08 21:41:26 +0000:
> 
> On 11/8/16, 9:08 AM, "Doug Hellmann" <doug at doughellmann.com> wrote:
> 
> >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.
> 
> Doug,
> 
> I’d like to maintain history for both the repos, and then selectively remove the stuff not neeeded for each repo (so they will then diverge).

Sure, that's one way to do it. I recommend picking just one of the
repos to have the old tags. I'm not sure if it would be simpler to
keep them in the repo that is current (openstack/kolla, I think?)
because artifact names for the old versions won't change that way,
or to keep all of that history and the stable branches in the repo
where you'll be doing new work to make backporting simpler.

What's the difference between kolla and kolla-ansible?

> >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).
> 
> Ok that works.  I think the lesson there is we can’t change the past :)  I think we would want kolla-ansible 
> 
> >
> >Do you maintain stable branches? Are those being kept in openstack/kolla
> >or openstack/kolla-ansible?
> Great question and something I hadn’t thought of.
> 
> Yes we maintain stable branches for liberty, mitaka, and newton.  I’m not sure if a stable branch for liberty is in policy for OpenStack.  Could you advice here?

Liberty is scheduled to be EOL-ed around 17 Nov, so if you have the
branch I would keep it for now and go through the EOL process normally.

> 
> I believe the result we want is to maintain the stable branches for liberty/mitaka/newton in kolla and then tag kolla-ansible Ocata as 4.0.0.  I don’t know if we need the 1/2/3 tags deleted in this case.  Could you advise?
> 
> Thanks for your help and contributions Doug :)
> 
> Regards
> -steve
> 
> >
> >Doug
> >
> >__________________________________________________________________________
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list