On Thu, Apr 9, 2015 at 11:23 AM, Akihiro Motoki <[email protected]> wrote:
> Neutron team has a plan to release a new version of neutornclient for Kilo. > We waited the new release until all granted FFE patches land, > and now we are almost ready to go. (waiting one patch in the gate) > > The planned new version is 2.4.0. It is because neutronclient uses 2.3.x > version > for a long time (including Kilo) and we would like to have a room for > bug fixing for Juno release. > So we would like to propose the following for Kilo: > > python-neutronclient >=2.4.0 <2.5.0 > > I am in the same page with Kyle. > I hope this plan is acceptable. > > Can we request a requirements FFE for the following patch [1]? This will set Liberty up to use the 2.5.x series for python-neutronclient, per what Akihiro and I have planned. The Juno patch should hopefully merge soon [2], which caps Juno to something appropriate as well. Thanks Kyle [1] https://review.openstack.org/#/c/172149/ [2] https://review.openstack.org/#/c/172150/ > Thanks, > Akihiro > > > 2015-04-10 0:09 GMT+09:00 Thierry Carrez <[email protected]>: > > Doug Hellmann wrote: > >> Excerpts from Dean Troyer's message of 2015-04-08 09:42:31 -0500: > >>> On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez <[email protected]> > >>> wrote: > >>> > >>>> The question is, how should we proceed there ? This is new procedure, > so > >>>> I'm a bit unclear on the best way forward and would like to pick our > >>>> collective brain. Should we just push requirements cap for all > OpenStack > >>>> libs and create stable branches from the last tagged release > everywhere > >>>> ? What about other libraries ? Should we push a cap there too ? Should > >>>> we just ignore the whole thing for the Kilo release for all non-Oslo > stuff > >>>> ? > >>> > >>> Provided that represents the code being used for testing at this > point, and > >>> I believe it does, this seems like a sensible default action. Next > cycle > >>> we can make a bit more noise about when this default action will occur, > >>> probably pick one of the other existing dates late in the cycle such > as RC > >>> or string freeze or whatever. (Maybe that already happened and I can't > >>> remember?) > >> > >> I had hoped to have the spec approved in time to cut releases around > >> the time Oslo did (1 week before feature freeze for applications, > >> to allow us to merge the requirements cap before applications > >> generate their RC1). At this point, I agree that we should go with > >> the most recently tagged versions where possible. It sounds like > >> we have a couple of libs that need releases, and we should evaluate > >> those on a case-by-case basis, defaulting to not updating the stable > >> requirements unless absolutely necessary. > > > > OK, here is a plan, let me know if it makes sense. > > > > If necessary: > > Cinder releases python-cinderclient 1.1.2 > > Designate releases python-designateclient 1.1.2 > > Horizon releases django_openstack_auth 1.2.0 > > Ironic releases python-ironicclient 0.5.1 > > > > Then we cap in requirements stable/kilo branch (once it's cut, when all > > RC1s are done): > > > > python-barbicanclient >=3.0.1 <3.1.0 > > python-ceilometerclient >=1.0.13 <1.1.0 > > python-cinderclient >=1.1.0 <1.2.0 > > python-designateclient >=1.0.0 <1.2.0 > > python-heatclient >=0.3.0 <0.5.0 > > python-glanceclient >=0.15.0 <0.18.0 > > python-ironicclient >=0.2.1 <0.6.0 > > python-keystoneclient >=1.1.0 <1.4.0 > > python-neutronclient >=2.3.11 <2.4.0 > > python-novaclient >=2.22.0 <2.24.0 > > python-saharaclient >=0.8.0 <0.9.0 > > python-swiftclient >=2.2.0 <2.5.0 > > python-troveclient >=1.0.7 <1.1.0 > > glance_store >=0.3.0 <0.5.0 > > keystonemiddleware >=1.5.0 <1.6.0 > > pycadf >=0.8.0 <0.9.0 > > django_openstack_auth>=1.1.7,!=1.1.8 <1.3.0 > > > > As discussed we'll add openstackclient while we are at it: > > > > python-openstackclient>=1.0.0,<1.1.0 > > > > That should trickle down to multiple syncs in multiple projects, which > > we'd merge in a RC2. Next time we'll do it all the same time Oslo did > > it, to avoid creating unnecessary respins (live and learn). > > > > Anything I missed ? > > > > Bonus question: will the openstack proposal bot actually propose > > stable/kilo g-r changes to proposed/kilo branches ? > > > > -- > > 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 > > > > -- > Akihiro Motoki <[email protected]> > > __________________________________________________________________________ > 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
