[openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications
slukjanov at mirantis.com
Tue Jun 16 09:31:23 UTC 2015
I have a question regarding proposed release versions - are we starting to
count releases from zero? And 2015.1 (Kilo) missed in all projects in
etherpad. So, it means if we're starting from 0.0.0 then the proposed
versions are correct, but if we want to start from 1.0.0 (IMO it's better),
we should increment all proposed versions.
Re Sahara version I think it'll be more logical to count 0.X releases as a
single version 0.X and start from 1.0.0 for Icehose, 2.0.0 for Juno and
3.0.0 for Kilo, so, for Sahara I think anyway it'll be better to start
versioning from 4.0.0.
On Tue, Jun 16, 2015 at 12:04 PM, Ihar Hrachyshka <ihrachys at redhat.com>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 06/16/2015 09:44 AM, Thierry Carrez wrote:
> > Doug Hellmann wrote:
> >> [...] I still need to chat with Kyle about some of the neutron
> >> spin-out projects, since their repositories have the old neutron
> >> tags but I don't think it's appropriate to use the same version
> >> number as neutron for newer projects. [...] neutron 8.0.0
> >> neutron-fwaas neutron-lbaas neutron-vpnaas
> > In Kilo (where they were introduced) those were released as a
> > single deliverable made of 4 source code tarballs. They would do
> > release candidates together, release together. My understanding is
> > that they are not versioned separately, they are supposed to be
> > used at the same version together.
> > If that assumption is correct, I think we should still consider it
> > a single deliverable with a single version scheme, and have the
> > neutron-*aas all starting at 8.0.0.
> Yes, please don't assume they are independent, at least for now while
> *aas don't have their own API endpoints.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> -----END PGP SIGNATURE-----
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev