Open Stack

On Wed, Jun 03, 2015 at 02:01:06PM +0100, John Garbutt wrote:
> Hi,
> 
> (To be clear, this is a proposal to be discussed and not a decision.)
> 
> The version number can help us communicate that:
> * you can consume a milestone release
> ** ... but the docs and translations may not be totally up to date
> * you can consume any commit
> ** ... but there is no formal tracking of bugs and features in that commit
> ** ... but can still live upgrade from the previous release to any
> commit in the current release
> * if you need completed docs and translations, wait for the final
> liberty release
> * we only support upgrade between <N>.x and <N+1>.x
> ** to ensure we can do live upgrades, but with minimal technical debt over time
> ** http://docs.openstack.org/developer/nova/devref/project_scope.html#upgrade-expectations
> 
> The idea is to keep what we do today, but try and communicate what
> that is a little better. Making it clear you can consume the milestone
> releases, and indeed the master branch, if thats what you want to,
> while being clear about what you loose and/or gain over waiting for
> the final release and/or stable branch.
> 
> Given we are thinking Liberty is moving to semantic versioning, maybe
> it could look like this:
> * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag
> * 12.0.2.dev1 is the first commit after 12.0.1 and does not get a tag
> * 12.0.2.dev1234 would be the 1234th commit after 12.0.1
> * 12.0.2 (liberty-2) will also contain features
> * 12.0.3 (liberty-3) is focused on priority features (given the current plan)
> * 12.1 is Liberty release is just bug fixes on 12.0.3
> * 13.0.0.dev1 would be the first commit to open M

FYI for reference, I have previously suggested that we make
intermediate releases on a 2 monthly cadence which, with all
releases being treated in the same way as production ready,
deployable releases

  http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html

What John is suggesting doesn't go as far as my proposal, since it
is still describing that the milestones releases have a specific
focus (features vs priority features vs bugs).

None the less, I think this suggestion on versioning would be a
step forward as it does improve the messaging to encourage the
idea that the milestone releases are not just thrown over the
wall for adhoc testing, but are in fact formal releases in their
own right that can be used for production if desired.

Perhaps in the future we'll move further towards the model I
had outlined, but this is a good start in that direction at
least.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|