[Evolution-hackers] Reconsidering our release cycle

[Matthew Barnes <mbarnes redhat com>]

I've been kicking around this idea for awhile now, but haven't said
anything until now.  I'm putting it out there as food for thought.

Increasingly I'm feeling like the traditional 6-month release cycle is
just too short for Evolution.  In terms of development, we have a pretty
short window for landing major changes and allowing adequate time for
testing before development freezes set in.

But more importantly, our users seem to be constantly playing catch-up
in terms of supported releases.  Because of the delay between upstream
releases and distro releases, by the time users finally upgrade to a
newer Evolution, more often than not they're upgrading to a version
that's either nearing the tail end of its 6-month support window or is
already unsupported.

That's frustrating, both for users and for me as a developer, but we
just don't have the manpower to support multiple stable releases and
still get any kind of significant development work done.

I'd like us to consider moving to a 12-month release cycle, which would
sync up with GNOME's release schedule annually instead of semi-annually.

Here's my initial proposal, if you guys are open to this:

* Continue with the 6-month releases through the end of the year, just
  because I think we need more lead time for such a major policy change.

* Bump Evolution's major version number to split away from GNOME's
  semi-annual release numbering.  Call the upcoming March 2014 release
  Evolution 4.0 (or perhaps even Evolution 2014... I'm open to ideas).

* We would follow GNOME's string change announcement and freeze schedule
  in the months leading up to each March release.

* We would continue releasing stable updates and development snapshots
  at a steady pace.  Our release schedule could even be more predictable
  than it is now.  We could do, for example, stable releases on the 1st
  Monday of each month and development snapshots on the 3rd Monday.

Obviously there's more details to figure out, but I like the precedent
we've set with the 3.8 branch, and I think our users appreciate it too.

My feeling is just that at this point in the project's lifespan, our
users would be better served by a longer support window.  They still
want to see improvements and new features, but more than anything I
think they just want stability and to see their bugs fixed without
waiting half a year.

It's just an idea.  What do you guys think?

Matt