> 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? Thanks, -Doug Mendizabal -------------------- Douglas Mendizábal IRC: redrobot PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
