Open Stack

On 20 April 2015 at 04:54, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:

>> Could you enlarge on what 'coordinating the requirements' means?
>>
>
> This is simply a choice to adhere to the global-requirements for a given
> release (e.g. Liberty) that nova (and other projects) adhere to. We won't be
> doing "a release when we feel like it" we will be doing a standard
> mile-stone tag for (example) L1, L2, L3, and Liberty final. We will then
> maintain the backport for stable/Liberty for the life of the release.

I'm confused ;). In a couple of ways.

Firstly, gloal-requirements and release-schedule are two different
dimensions. They connect in that some changes to global-requirements
are coordinated with the 6-month release schedule, but its a fairly
open relation: you can release whenever you like (like Swift does) and
still coordinate with global-requirements.

Secondly, how will e.g. nova depend on new functionality in
keystonemiddleware? I presume you'll make nova depend on the L1
release after its done, and block consuming the new functionality
until the middleware has released?
...
> Today middleware is released independent of everything (like a client) but
> since it is tightly coupled to a set of requirements using 1.5.x with Juno
> is challenging, since there is a requirements mismatch. Today the only way
> you know what versions work is by either looking at release dates or by
> trial/error (or examining requirements). I think it is far better to release
> middleware like a server project to more clearly indicate release schedule
> and compatibility.

Whats the coupling there? More specifically, is it 'the middleware
needs other components that don't have stable APIs' or, as I
suspect,is it really https://github.com/pypa/pip/issues/988 (and
associated glitches) - which I'm fixing as we speak...

Generally in dependency relationships semver should be enough: I'm
very worried that you seem to be saying that semver *does not* work
here, and I want to understand the details (independent of whatever
keystonemiddleware does), so that work on pbr and other parts of our
release process is fully informed.

> Knowing that 1.3.x receives backports (and tied to Juno), but 1.4.x doesn't
> because it was released between Juno and kilo, and 1.5.x does again (and is
> tied to kilo) is just a poor experience for our deployers. I don't want to
> have to name some release LTS of keystonemiddleware, let's  release in a way
> that make sense for how it is used.

But all three are compatible based on their version: anything that
worked with 1.3 should work with 1.5. Why doesn't it?

> Details of the version numbers will be hashed out at the summit and the
> release management team. (E.g do we move to a 2015.x.x model? Do we
> increment the X per release in semver, or the 'y'?) This part is not yet
> determined and requires some discussion.

Indeed.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud