On Thu, Jan 29, 2015 at 2:22 PM, Douglas Mendizabal < [email protected]> wrote:
> > On Jan 29, 2015, at 1:19 PM, Doug Hellmann <[email protected]> wrote: > > > > On Thu, Jan 29, 2015, at 01:31 PM, Joe Gordon wrote: > > On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague <[email protected]> wrote: > > So, honestly, yes. > > For a library to release safely it must: > > * have stable-compat jobs running (this was the issue with barbican client) > * if it has a stable/juno branch it must be pinned in stable/juno (this > was the issue on most of the oslo libs) > > > > [snip] > > Thanks to both of you for working on this! > > Doug > > > [snip] > > +1 I definitely appreciate all the help sorting this out. I think it’s > good that we’ll have a stable-compat job in our gate now, but it’s still > not clear to me how this would have prevented the problem? Sure, we could > have noticed that the global-requirements-sync CR was a breaking change in > cinder/juno, but by that point the offending oslo library was already in > global-requirements. > > I’m still not sure what the barbican team needs to do going forward. It > seems that pinning an oslo lib pretty much forces every client using it to > fork a stable branch? If so, should we plan on supporting a stable/juno > branch in python-barbicanclient which forks at 3.0.1 (the last juno > compatible release?) and then back port fixes as 3.0.1.x? > Going froward, we will pin the use of all uncapped libraries (including python clients) and not require dependency comparability with stable branches. This means if any bug or security fix is needed, you will need to backport it to a compatible cient version (done via a version range, or a compatible release: https://www.python.org/dev/peps/pep-0440/#compatible-release). So to answer your question, you may need to back port fixes to 3.0.1.x. > > Thanks, > -Doug Mendizabal > > -------------------- > Douglas Mendizábal > IRC: redrobot > PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
