Folks, I want to bring this up again. There were no progress since last Oleg's mail, and we must decide. It's good that we still have "2015.1.0-8.0" version while OpenStack uses "Liberty" name for versions.
Let's decide which name to use, file a bug and finally resolve it. - Igor On Thu, Oct 22, 2015 at 10:23 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > Igor, it is interesting that you mention backward compatibility in this > context. > > I can see lots of code in Nailgun that checks for release version to > enable/disable features that were added or removed more than 2 releases > before [1] [2] [3] (there's a lot more). > > What should we do about that code? I believe we could 'safely' delete it. It > will make our code base much more compact and supportable without even > decoupling serializers, etc. Is my assumption correct, or I just missing > something? > > This will also help to switch to another scheme of versioning of releases, > since there will be much less places where those version scheme is > hardcoded. > > [1] > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/release.py#L142-L145 > [2] > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L554-L555 > [3] > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/serializers/node.py#L124-L126 > > -- > Best regards, > Oleg Gelbukh > > On Mon, Oct 19, 2015 at 6:34 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> 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 > > > > __________________________________________________________________________ > 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