On 15 April 2015 at 09:33, Joe Gordon <joe.gord...@gmail.com> wrote: > > > On Tue, Apr 14, 2015 at 2:36 AM, Thierry Carrez <thie...@openstack.org> > wrote: >> >> Robert Collins wrote: >> > On 13 April 2015 at 22:04, Thierry Carrez <thie...@openstack.org> wrote: >> >> How does this proposal affect stable branches ? In order to keep the >> >> breakage there under control, we now have stable branches for all the >> >> OpenStack libraries and cap accordingly[1]. We planned to cap all other >> >> libraries to "the version that was there when the stable branch was >> >> cut". Where would we do those cappings in the new world order ? In >> >> install_requires ? Or should we not do that anymore ? >> >> >> >> [1] >> >> >> >> http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html >> > >> > I don't think there's a hard and fast answer here. Whats proposed >> > there should work fine. >> > [...] >> > >> > tl;dr - I dunno :) > > > This is the part of the puzzle I am the most interested in. Making sure > stable branches don't break out from underneath us forcing us to go into > fire fighting mode.
I think this is very important too. The spec that James linked to https://review.openstack.org/#/c/161047/ seems broadly to be heading in the right direction to me - my -1 on it is because the described failure mode is very solvable vs e.g. failure modes where dependencies release broken stuff. It is in short 'make a fully specified requirements list and use that via pip -r in stable branch gate jobs'. I think thats entirely sane (and have been discussing that in various places for a while :)). *this* thread is about making install_requires, which we currently source from requirements.txt, be sourced separately (from setup.cfg) and then we don't need per-repo requirements.txts, which will align us with the broader ecosystem as far as the definition of requirements.txt. We *do* have uses for fully specified things, and one of them is 'what worked in that test run', which is what the etherpad is intended to capture. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev