Doug Hellmann wrote: > Excerpts from Ben Swartzlander's message of 2015-09-04 16:54:13 -0400: >> [...] >> I would actually want to release a milestone between L-3 and RC1 after >> we get to the real Manila FF date but since that's not in line with the >> official release process I'm okay waiting for RC1. Since there is no >> official process for client releases (that I know about) I'd rather just >> wait to do the client until RC1. We'll plan for an early RC1 by >> aggressively driving the bugs to zero instead of putting time into >> testing the L-3 milestone. > > If master is broken right now, I agree it's not a good idea to > release. That said, you still don't want to wait any later than > you have to. Gate jobs only install libraries from packages, so no > projects that are co-gating with manila, including manila itself, > are using the source version of the client library. That means when > there's a release, the new package introduces all of the new changes > into the integration tests at the same time.
Yes, that creates unnecessary risk toward the end of the release cycle. This is why we want to release near-final version of libraries this week (from which we create the library release/stable branches) -- to keep risk under control and start testing with the latest code ASAP. > We want to release clients as often as possible to keep the number > of changes small. This is why we release Oslo libraries weekly -- > we still break things once in a while, but when we do we have a > short list of changes to look at to figure out why. > > I'll be proposing that we do a weekly client change review for all > managed clients starting next cycle, and release when there are changes > that warrant (probably not just for requirements changes, unless > it's necessary). I haven't worked out the details of how to do the > review without me contacting release liaisons directly, so suggestions > on that are welcome. +1 -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
