Oleg, I think we can remove this function for new releases and keep them only for backward compatibility with previous ones. Why not? If there's a way to do things better let's do them better. :)
On Sat, Oct 17, 2015 at 11:50 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > In short, because of this: > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/release.py#L74-L99 > > Unless we use dashed 2-component version where OpenStack version comes > first, followed by version of Fuel, this will break creation of a cluster > with given release. > > -Oleg > > On Sat, Oct 17, 2015 at 10:24 PM, Sergii Golovatiuk > <sgolovat...@mirantis.com> wrote: >> >> Why can't we use 'liberty' without 8.0? >> >> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh <ogelb...@mirantis.com> wrote: >>> >>> After closer look, the only viable option in closer term seems to be >>> 'liberty-8.0' version. It does not to break comparisons that exist in the >>> code and allows for smooth transition. >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> >>> On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky <ikalnit...@mirantis.com> >>> wrote: >>>> >>>> Oleg, >>>> >>>> Awesome! That's what I was looking for. :) >>>> >>>> - Igor >>>> >>>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh <ogelb...@mirantis.com> >>>> wrote: >>>> > Igor, >>>> > >>>> > Got your question now. Coordinated point (maintenance) releases are >>>> > dropped. >>>> > [1] [2] >>>> > >>>> > [1] >>>> > http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html >>>> > [2] >>>> > >>>> > https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases >>>> > >>>> > -- >>>> > Best regards, >>>> > Oleg Gelbukh >>>> > >>>> > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky >>>> > <ikalnit...@mirantis.com> >>>> > wrote: >>>> >> >>>> >> Oleg, >>>> >> >>>> >> Yes, I know. Still you didn't answer my question - are they planning >>>> >> to release stable branches time-to-time? Like I said, Liberty is >>>> >> something similar 2015.2.0. How they will name release of something >>>> >> like 2015.2.1 (stable release, with bugfixes) ? Or they plan to drop >>>> >> it? >>>> >> >>>> >> Thanks, >>>> >> Igor >>>> >> >>>> >> On Fri, Oct 16, 2015 at 1:02 PM, Oleg Gelbukh <ogelb...@mirantis.com> >>>> >> wrote: >>>> >> > Igor, >>>> >> > >>>> >> > The point is that there's no 2015.2.0 version anywhere in >>>> >> > OpenStack. So >>>> >> > every component will be versioned separately, for example, in >>>> >> > Libery, >>>> >> > Nova >>>> >> > has version 12.0.0, and minor release of it is going to have >>>> >> > version >>>> >> > 12.0.1, >>>> >> > while Keystone, for instance, will have version 11.0.0 and 11.0.1 >>>> >> > for >>>> >> > minor >>>> >> > release. >>>> >> > >>>> >> > The problem in Fuel is that coordinated release version is used in >>>> >> > several >>>> >> > places, the most important being installation path of the >>>> >> > fuel-library. >>>> >> > We >>>> >> > won't be able to use it the same way since Liberty. I'd like to >>>> >> > understand >>>> >> > how we are going to handle that. >>>> >> > >>>> >> > My suggestion actually is to move away from using OpenStack version >>>> >> > as a >>>> >> > part of Fuel version. Then the path to install the fuel-library >>>> >> > will be >>>> >> > '/etc/puppet/8.0.0/'. >>>> >> > >>>> >> > -- >>>> >> > Best regards, >>>> >> > Oleg Gelbukh >>>> >> > >>>> >> > On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky >>>> >> > <ikalnit...@mirantis.com> >>>> >> > wrote: >>>> >> >> >>>> >> >> Hey Oleg, >>>> >> >> >>>> >> >> I've read the post [1] and I didn't get how exactly minor releases >>>> >> >> of >>>> >> >> *stable* branch will be versioned? >>>> >> >> >>>> >> >> Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned? >>>> >> >> >>>> >> >> [1] http://ttx.re/new-versioning.html >>>> >> >> >>>> >> >> Thanks, >>>> >> >> Igor >>>> >> >> >>>> >> >> >>>> >> >> On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh >>>> >> >> <ogelb...@mirantis.com> >>>> >> >> wrote: >>>> >> >> > Hello, >>>> >> >> > >>>> >> >> > I would like to highlight a problem that we are now going to >>>> >> >> > have in >>>> >> >> > Fuel >>>> >> >> > regarding versioning of OpenStack. >>>> >> >> > >>>> >> >> > As you know, with introduction of the Big Tent policy it was >>>> >> >> > decided >>>> >> >> > that >>>> >> >> > since Liberty dev cycle versioning schema of the whole project >>>> >> >> > changes. >>>> >> >> > Year-based versions won't be assigned to individual projects, >>>> >> >> > nor the >>>> >> >> > coordinated release is going to have unified number [1]. >>>> >> >> > Individual >>>> >> >> > projects >>>> >> >> > will have semver version numbers, while numbering of the release >>>> >> >> > itself >>>> >> >> > seems to be dropped. >>>> >> >> > >>>> >> >> > However, in Fuel there is a lot of places where we use >>>> >> >> > year-based >>>> >> >> > version of >>>> >> >> > OpenStack release. [2] How are we going to handle this? Shall we >>>> >> >> > have >>>> >> >> > openstack_version: 2015.2 all over the place? Or we should come >>>> >> >> > up >>>> >> >> > with >>>> >> >> > something more sophisticated? Or just drop OpenStack version >>>> >> >> > component >>>> >> >> > from >>>> >> >> > our versioning schema for good? >>>> >> >> > >>>> >> >> > Please, share your opinions here or in corresponding reviews. >>>> >> >> > >>>> >> >> > [1] http://ttx.re/new-versioning.html >>>> >> >> > [2] https://review.openstack.org/#/c/234296/ >>>> >> >> > >>>> >> >> > -- >>>> >> >> > Best regards, >>>> >> >> > Oleg Gelbukh >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > __________________________________________________________________________ >>>> >> >> > 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 >>>> >> >> > >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> __________________________________________________________________________ >>>> >> >> 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 >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > __________________________________________________________________________ >>>> >> > 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 >>>> >> > >>>> >> >>>> >> >>>> >> __________________________________________________________________________ >>>> >> 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 >>>> > >>>> > >>>> > >>>> > >>>> > __________________________________________________________________________ >>>> > 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 >>>> > >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>> >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> >> __________________________________________________________________________ >> 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 >> > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
