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

[Matt Mackall]

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.

-- 
Mathematics is the supreme nostalgia of our time.