Yup. Frequent releases, some focused on getting to stable on older code lines, some pushing new code out for people to try.
On Jun 21, 2011, at 11:40 AM, Roy T. Fielding wrote: > On Jun 21, 2011, at 4:39 AM, Steve Loughran wrote: > >> On 18/06/2011 21:22, Roy T. Fielding wrote: >> olutely no reason that trunk cannot be packaged for release >>> tomorrow as 0.23. There may be many reasons why it won't pass a release >>> vote, but we probably aren't going to find them until somebody tries. >> >> One limitation with releases has always been size of cluster testing -where >> Yahoo!s contributions have been invaluable. That said, we shouldn't make >> them an SPOF in the release process; we should all set up to do some more >> release testing. > > Yes, more testing is better, but if it can't be tested by the dev team > in 72 hours then it doesn't belong in our release process. > > Please note that one of the main advantages of open source development > is that the bulk of testing/QA occurs *after* the release. That's why > labels like alpha/beta/GA are best applied/updated after the version number > has been cut and the software has been proven in real deployments. > If testing on 5000 nodes is important to our customers, then add a > scale-tested metric to the download site so that the customers know > which release package has been tested at what scale -- they will > understand the difference between frequent releases and those fully tested > at scale. Let them decide which version is best to use for their own needs. > > ....Roy >
