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
