On 20 April 2015 at 04:54, Morgan Fainberg <[email protected]> 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 <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
