Two major releases per year instead of three

[Adrian Buehlmann]

On 2011-07-26 12:32, Adrian Buehlmann wrote:
> http://mercurial.selenic.com/wiki/TimeBasedReleasePlan
> 
> I'm voting for doing two major releases per year instead of three.
> 
> 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).
> 
> And Mercurial users are increasingly skipping major releases, for
> various reasons.
> 
> Humans are also better at remembering what happened in half-year periods
> and quarters. 4 month periods may be cute, but they are just odd.
> 
> Also, two major events per year is more attractive for users than three.
> I think the third one gets boring for users.
> 
> IMHO, three times a year is just one too much.
> 
> [1] https://bitbucket.org/tortoisehg/thg/issue/937

I think leaving away the July 1st release date could work fine. Lots of
people are on holidays during the summer in Europe and quite a number of
developers seem to disappear right after this date, which makes its
first bugfix release date (Aug 1st) quite problematic in my view.

Just ask yourself: Are users really going to upgrade to the July 1st
release right before or in the middle of the summer holidays? I don't
think so. At least not in Europe.

I think moving the March 1st date by two months to May 1st wouldn't be
that bad. So people would have time to recover from the end of year
holiday season (and the end of year activities for those having to do
accounting :-).

The Nov 1st date could stay as it is.

Having two big releases per year would also free up developer time,
since every major release means some work that needs to be done. If
users don't upgrade to some releases anyway, why investing (and wasting)
this work?

Asking users to test release candidates twice a year might actually give
more pre-release feedback compared to asking users to do this three
times a year.

I think pre-release user testing is rather weak currently. Too many
users (and extension authors) are just lazy and simply wait for the
"real" release date, hoping other users will iron out the kinks for them.

If we have only two feature releases per year, the releases will most
likely also be more attractive for users, since they will likely contain
more new features per release. Which increases motivation to help
testing pre-releases and motivation to actually *do* the upgrade.

Having two releases instead of three would make it easier to allow a bit
longer freeze phases, as there would still be enough "unfrozen" time
available for development between releases.

And maybe those who try bringing in those big changes _right_ after a
major release would pay a bit more attention to the schedule in the
future, making sure they don't miss the release date. With only two
releases per year, the motivation to take the schedule a bit more
seriously, should be bigger.