Excerpts from Ihar Hrachyshka's message of 2016-03-24 08:44:35 +0100: > Doug Hellmann <d...@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 __________________________________________________________________________ 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