Open Stack

Excerpts from Alan Pevec's message of 2016-03-24 17:06:54 +0100:
> > So, if Delorean includes packages built from untagged commits in
> 
> Nit clarification: let's call it RDO Trunk repository (Delorean is a
> tool, recently renamed https://github.com/openstack-packages/dlrn )

OK.

> 
> > 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?
> 
> It is not what happens, there are separate repositories for packages
> built from master and stable branches

Good.

> but it is still confusing, and
> I'm not sure why is such a big deal to just push one empty commit with
> Sem-Ver: api-break when we have that nice PBR automagic ?

There are a couple of reasons, mostly having to do with the fact
that we're trying to reduce the amount of work it takes to handle
releases so we can start encouraging more projects to do them more
often.

First, every extra step that we have to take during the release
processing is another opportunity for it to go wrong, especially
if we have to do them in a particular sequence. We have, this cycle,
mostly eliminated the in-tree sequential operations. There are still
a few gotchas in the steps the release team actually goes through,
but the negative side-effects of getting those wrong (or in the
wrong order) is mostly small.

As you point out below, we used to require a patch immediately after
a branch to change the version numbering from pre-versioning (declared
in setup.cfg) to post-versioning (declared using tags). That required
a higher level of coordination, even with a small number of teams
very engaged in the release process. We now have too many teams,
releasing too many deliverables, with too few people who understand
how we manage releases. We mostly have everyone up to speed on
SemVer and requesting releases, but not quite.

The second reason is that there's not necessarily an API break at
every release cycle, and not all projects increment their major
version number just because of the cycle. So we would actually end
up doing something different for each project, depending on how
they treat release boundaries, and that's yet another thing to keep
track of, review carefully, and educate folks about when preparing
the release and stable branches.

> Previously pre-versioning was used and version had to be bumped
> explicitly in setup.cfg when opening master for the new version e.g.
> https://review.openstack.org/#q,Ib634eb7acb64ff1d7be49852972295074b11557a,n,z
> 
> Another example (not release:managed project but still) where we have
> this confusion is gnocchi:
> openstack/gnocchi > master $ python ./setup.py --version
> 2.0.1.dev61
> openstack/gnocchi > stable/2.0 $ python ./setup.py --version
> 2.0.3.dev13

Let's turn the question around: Why do you (or anyone) want to
package things that are not tagged as releasable by the contributors
creating them? What are those packages used for?

Doug

> 
> Cheers,
> Alan
>