Four! was Re: Two major releases per year instead of three

[Matt Schulte]

On Thu, Aug 4, 2011 at 1:34 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2011-07-26 at 12:32 +0200, Adrian Buehlmann wrote:
>> http://mercurial.selenic.com/wiki/TimeBasedReleasePlan
>>
>> I'm voting for doing two major releases per year instead of three.
>
> I've actually been thinking for a while that we should go to four.
>
>> For example, we're still trying to figure out on TortoiseHg how to fix
>> the collateral damage caused by the last-minute command server changes
>> done in 1.9 (actually, it feels like no one is looking at things like
>> [1] right now).
>
> Lowering the release frequency will actually probably make that worse,
> not better.
>
>> And Mercurial users are increasingly skipping major releases, for
>> various reasons.
>
> But importantly, they don't skip them as a herd. There are plenty of
> users still on 1.0 - that's fine so long as significant numbers of
> people use 1.9. People can stick with 1.0 as long as it suits them.
>
> I chose 3 releases per year rather than 2 initially because 6 months was
> clearly too long a wait for both developers and users alike. And it's
> beginning to seem like 4 months is too long too.
>
> Shorter cycles mean:
>
> - developers can get their work in the hands of users and get feedback
> more quickly -> developers do more work!
> - users can get new features more rapidly -> happier users!
> - fewer API changes between releases make it easier for third parties to
> synchronize
>
> The obvious response is "if shorter is better, why not make releases
> every month?" And the answer is: we could easily do that, and it would
> actually be less work for me. I'd maintain a single branch and just cut
> releases from it monthly. But I don't think third-party projects would
> be pleased with potentially having to cut their own monthly releases.
>
> So I've actually been thinking of switching to 3 month cycles after 2.0.
> That would give us major releases on Nov 1, Feb 1, May 1, and Aug 1.
> This would also align better with the 6-month release cycles of Ubuntu
> and Fedora.
>
> We could probably also plan on having sprints twice a year rather than
> every 8 months.
>

I just had this idea when reading your post and I thought I'd throw it
out there.

What if you sort of had the best of both worlds:

4 releases a year but 2 of them would be a little more experimental
and 2 would be more stable.

Something like:
1.9.0 = stable
1.9.1 = experimental
1.9.2 = stable
1.9.3 = experimental

Matt Schulte