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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
