Open Stack

Excerpts from Ihar Hrachyshka's message of 2016-03-24 08:44:35 +0100:
> Doug Hellmann <doug at doughellmann.com> wrote:
> 
> > Excerpts from Alan Pevec's message of 2016-03-22 20:19:44 +0100:
> >>> The release team discussed this at the summit and agreed that it didn't  
> >>> really matter. The only folks seeing the auto-generated versions are  
> >>> those doing CD from git, and they should not be mixing different  
> >>> branches of a project in a given environment. So I don't think it is  
> >>> strictly necessary to raise the major version, or give pbr the hint to  
> >>> do so.
> >>
> >> ok, I'll send confused RDO trunk users here :)
> >> That means until first Newton milestone tag is pushed, master will
> >> have misleading version. Newton schedule is not defined yet but 1st
> >> milestone is normally 1 month after Summit, and 2 months from now is
> >> rather large window.
> >>
> >> Cheers,
> >> Alan
> >
> > Are you packaging unreleased things in RDO? Because those are the only
> > things that will have similar version numbers. We ensure that whatever
> > is actually tagged have good, non-overlapping, versions.
> 
> RDO comes in two flavours. One is ‘classic’ RDO that builds from tarballs.
> 
> But there’s also another thing in RDO called Delorean which is RDO packages  
> built from upstream git heads (both master and stable/*).
> 
> More info:  
> http://blogs.rdoproject.org/7834/delorean-openstack-packages-from-the-future
> 
> It allows to install the latest and greatest from upstream heads. Two  
> options are available: running from ‘current’ which is unvalidated latest  
> heads, or rely on ‘current-passed-ci’ that points to the latest build that  
> was validated by CI.
> 
> Ihar
> 

The assumption we're working under is that someone would choose
between three options when installing, regardless of the form of
the thing they install (direct from git, wheels, self-made packages
of another type, distro packages, whatever):

1. Tagged versions from any branch.
2. Untagged versions on a stable branch.
3. Untagged versions on the master branch.

Option 1 is clear, and always produces deployments that are
reproduceable, with versions distinct and increasing over time.

Options 2 and 3 sometimes, right around release cycle boundaries,
produce the same version numbers in different branches for a short
period of time. The lack of distinct version numbers can produce
confusion (in humans and robots), but we thought it extremely
unlikely that anyone would mix option 2 and 3, because that way
lies madness for upgrades and understanding what you actually have
running in your cloud. Choosing either 2 or 3 is fine. Mixing is
not, and the *way* someone installs the code doesn't change the
fact that it's a bad idea to cross the streams.

So, if Delorean includes packages built from untagged commits in
multiple branches, placed in the same package repository where an
automated installation tool can't tell stable/mitaka from master,
that would be bad. Please tell me that's not what happens?

Doug