On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote: > As a way to get more user feedback on our major feature releases, what > does everyone think about releasing one or two -beta releases for each > major feature release? > > This might fall in line with some of the stated concerns about our > release schedule (see [1]). I've stated a desire to be quicker about > our releases (my vote was 4 months). I've also been saying quite > publicly that we should never release if we know about upgrade issues > (that's the cost of having actual users of our project, which I'm more > than willing for us to pay). > > Perhaps -betaX releases would be helpful to get attention from the users > to test the release (including upgrade paths). The stated assumption > could be: -beta releases are not releases that can be upgraded *from*, > but are intended to help support testing by end users that want to check > the upcoming release against their expected feature set and upgrade > path. > > I would see the first -beta-1 being released about 1 month after feature > freeze. For example, for 4.2.0, it would be on 2013-06-30. I would > only do a -beta-2 (or later) beta release if required due to testing > results. I would also suggest that the -beta-* releases would *not* > have any particular quality criteria (well... perhaps minimal, like > blocking on issues that fundamentally make the software unstable). > > I'm not sure about my own proposal here, but I wanted to throw it out > and see if any of you have feedback / thoughts. > > -chip > > [1] http://markmail.org/message/3ctdwor5hfbpa3vx
To summarize the discussions of this thread: 1) The idea of ensuring that we get user testing of release candidates is one that most agree with. 2) Concerns were raised about the overhead of "officially" releasing beta releases, especially if there is any expectation that there would be an upgrade path from a -beta to an official release. I'd like to simplify this by saying that we should actually plan on announcing the start of each round of voting on RC's to the users@ list. We can get feedback from them on each round. And while I don't really love having a bunch of rounds of voting, 4.1.0 has basically proven that user engagement testing the RC's is critical. I think that we might also consider (at a release manager's discretion) periodically announcing a request for testing of the feature branch's code during the QA part of our release cycles. Shout if you disagree.
