Re: [Evolution-hackers] Reconsidering our release cycle

[Fabiano Fidêncio <fabiano fidencio org>]

Matthew,

On Tue, Jul 23, 2013 at 4:10 PM, Matthew Barnes <mbarnes redhat com> wrote:
> 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

I also fully agree with your suggestion.

As we have discussed, users are reporting bugs against 3.8.x now and
they will need to wait at least 6 months before they get a fix in
3.10.x. I mean, from the stability point of view it would be great if
we have a larger window to work, test and correct our mistakes..


Best Regards,
-- 
Fabiano Fidêncio