Proposed stable/grizzly release dates
Hi all, I'd like to throw out some dates for discussion, based on folsom releases, which was about every 2 months: 2013.1 Grizzly release Apr 4 2013.1.1 Jun 6 2013.1.2 Aug 8 2013.1.3 Oct 10 Funnily enough, those Thursdays are all day_in_month# = month# which is nice to remember. Cheers, Alan
On 5 April 2013 23:15, Alan Pevec <apevec@gmail.com> wrote:
Hi all,
I'd like to throw out some dates for discussion, based on folsom releases, which was about every 2 months:
2013.1 Grizzly release Apr 4 2013.1.1 Jun 6 2013.1.2 Aug 8 2013.1.3 Oct 10
Funnily enough, those Thursdays are all day_in_month# = month# which is nice to remember.
Cheers, Alan
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
Hi Alan, It's looking like there is a steady stream of post release fixes coming through for Grizzly now. Therefore, I think we should consider a sooner release for the first one. But then, I still maintain that point releases isn't something that I think is useful. Thanks. -- Kind Regards, Dave Walker <Dave.Walker@canonical.com> Engineering Manager, Ubuntu Server
2013/4/6 Daviey Walker <dave.walker@canonical.com>:
It's looking like there is a steady stream of post release fixes coming through for Grizzly now. Therefore, I think we should consider a sooner
How soon you had in mind? Would it work to insert 2013.1.1 on May 9th and then release every 2 months: .2 Jun 6 .3 Aug 8 .4 Oct 10 ?
release for the first one. But then, I still maintain that point releases isn't something that I think is useful.
That sounds like there was a prior discussion which I missed, so I'm not sure if I understand right, but taking this to the extreme, we wouldn't need major releases either and just deploy from trunk. Was it the idea to maintain stable branch only as a repository of useful backports? IMHO best part of releases is a deadline, which usually motivates people to get work done. Cheers, Alan
On Mon, 2013-04-08 at 01:06 +0200, Alan Pevec wrote:
2013/4/6 Daviey Walker <dave.walker@canonical.com>:
It's looking like there is a steady stream of post release fixes coming through for Grizzly now. Therefore, I think we should consider a sooner
How soon you had in mind? Would it work to insert 2013.1.1 on May 9th and then release every 2 months: .2 Jun 6 .3 Aug 8 .4 Oct 10 ?
A .1 relatively soon after the release sounds like a good idea, assuming someone (e.g. Alan :) has the time to pull it together.
release for the first one. But then, I still maintain that point releases isn't something that I think is useful.
That sounds like there was a prior discussion which I missed, so I'm not sure if I understand right, but taking this to the extreme, we wouldn't need major releases either and just deploy from trunk.
Yeah, for me, releases from the stable branch are like errata for the main releases ... I hate to think of the project having e.g. 2012.2.tar.gz sitting on its site with major known issues and telling people "oh, ignore the tarball releases and just use the stable branch".
Was it the idea to maintain stable branch only as a repository of useful backports? IMHO best part of releases is a deadline, which usually motivates people to get work done.
There's going to be a design summit session on stable branch processes ... that's a good time for us to revisit what we're doing and discuss in detail. Cheers, Mark.
participants (3)
-
Alan Pevec
-
Daviey Walker
-
Mark McLoughlin