Open Stack

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 <
sgolovatiuk at mirantis.com> wrote:

> Why can't we use 'liberty' without 8.0?
>
> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh <ogelbukh at 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 <ikalnitsky at mirantis.com>
>> wrote:
>>
>>> Oleg,
>>>
>>> Awesome! That's what I was looking for. :)
>>>
>>> - Igor
>>>
>>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh <ogelbukh at 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 <
>>> ikalnitsky at 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 <ogelbukh at 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
>>> >> > <ikalnitsky at 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 <
>>> ogelbukh at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151017/c39a9efc/attachment.html>