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.