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

[Matt Schulte]

On Thu, Aug 4, 2011 at 2:11 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2011-08-04 at 13:50 -0500, Matt Schulte wrote:
>> 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
>
> Don't we already do that?
>
> Our current numbering scheme is:
>
> 1.x -> 3 major releases per year, every four months
> 1.x.y -> 3 (or more) minor stable releases between each major release,
> at least once a month
>
> In the proposed scheme, we'd be doing:
>
> 2.x -> 4 major releases per year, every three months
> 2.x.y -> 2 (or more) minor stable releases between each major release,
> at least once a month
>
> We have no shortage of stable releases. We currently have 9 or more per
> year, the proposed scheme would have 8 or more.

Sorry (I knew that my numbers would be a problem), how about this:

Something like:
1.9 = stable
2.0 = experimental
2.1 = stable
2.2 = experimental

That way those who don't necessarily want the latest greatest code can
skip the more experimental releases.  And those who like the adventure
of new stuff can grab the experimental releases.