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

[Adrian Buehlmann]

On 2011-08-04 20:34, Matt Mackall 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.

If that's the case, then I'm for trying 4 releases per year.

As per the "ecosystem has problems catching up" problem: I think it
doesn't matter if we have the "update hell" every 4 or every 3 months.
It most likely hurts almost equally for the ecosystem folks.

Actually, if there is a "bad fit" major release (from the viewpoint of a
particular dependent project or user), it will be easier to skip it,
because the next one is only 3 months away.

So consumers could skip every other major release, and they get the 6
months cycle.

>> 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

That might work, yes.

> 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.

I'm fine with this plan. Let's see if it is better than the current one.

> We could probably also plan on having sprints twice a year rather than
> every 8 months.