Open Stack

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?

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).
-- 
Jeremy Stanley