Open Stack

Excerpts from Jeremy Stanley's message of 2017-01-17 18:15:59 +0000:
> On 2017-01-17 18:48:59 +0100 (+0100), Dmitry Tantsur wrote:
> [...]
> > In theory there is nothing wrong with this, as 1.10 is the latest
> > release indeed. In practice, that means pulling in something with
> > stable/newton requirements into master, which is concerning, I
> > agree.
> [...]
> 
> I don't really see why this is a problem at all. The change in
> question updated master constraints from 1.9.0 (a pre-Newton
> release) to 1.10.0 (a stable Newton release). Did anything
> substantial change in stable/newton between 1.9.0 and 1.10.0 to make
> the newer version unsuitable for use with master branch versions of
> other projects? Newer is newer is newer. If projects need
> integration testing against the master branch (or any particular
> branch) of something, they need to be installing from source and not
> packages. If the package corresponding to this tag from the stable
> branch works with master versions of other projects, then it seems
> like our automation worked as intended. Is there a reason to think
> that our master branches should be using _older_ versions of
> dependencies than our stable branches?

>From our CI perspective, it doesn't matter. It looks a bit odd from the
perspective of us telling downstream packagers that the constraints list
is what they should be trying to bundle for compatibility. It's not
terribly weird, but I do see how it can introduce some confusion. Of
course the same case may come up frequently for dependencies of our
libraries.

> Granted, it's unclear to me why a stable branch got a release tagged
> with a version which semver says is more than straight up bug fixes.
> That would seem to fly in the face of stable branch change policy
> (but is orthogonal to the topic of this thread).

In this case there was a change in the dependencies of the library.
IIUC, the change wasn't "real" in the sense that the dependency was
always there, but the new version of the lib more accurately reflected
its dependencies.

Doug