Re: [Evolution-hackers] Reconsidering our release cycle

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

I  like the idea very much and had similar plans before, but never
went forward with it before.

I think I like the idea.

My concern is that it could also be longer before new features and fixes
actually make it into a release. For example, if we were on an annual
schedule and people were still using Evolution 3.6 today instead of
Evolution 3.8.... we'd still be having to kill evolution-source-registry
after connecting to the VPN if we actually want to see our calendars.

And if a distribution ships a few weeks before a release, that now means
they can be shipping a version of Evolution which is a *year* old,
instead of only six months old.

Life would be a lot easier even with the existing release cycle if we
weren't so incestuously tied to the latest GNOME release (and if the
GNOME libraries didn't make compatibility so hard by deprecating things
so quickly). Obviously we'll have to fix that anyway, and I wonder how
much of the proposed benefit we could achieve by *only* fixing that,
while sticking with 6-monthly releases on the GNOME schedule?

For example, if users could use Evolution 3.8 on top of GNOME 3.6, and
upgrading didn't mean they have to rebuild their *whole* world with it,
the existing situation wouldn't be quite so bad anyway, would it? 

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.

But we've never *prevented* any distro packager from continuing to do
maintenance for older releases. I did it for 2.32 for a while, when
MeeGo was using that.

If distributions want to cherry-pick patches back into an "unsupported"
release that they're using, we should encourage them to do so.

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:

Please take the above comments as just thinking aloud, rather than
objections. I'm more than happy to attempt what you propose.

On Tue, 2013-07-23 at 21:28 +0530, Srinivasa Ragavan wrote:
The challenge will be to sync properly with the GNOME freezes during
the second half of the cycle. It will be good to sync with that, so
that when the product releases with GNOME release, there is doc /
translation all ready.


I really wouldn't want EDS to be part of this, if we ever want it to
be a proper platform/core material. Just Evolution would be better fit
for this model IMHO.

I don't think that makes sense. As Fabiano points out, Evo and EDS are
*very* closely tied. Even in the *stable* branch in 3.8.4 there are
fixes for EDS/EWS which require corresponding fixes in Evo.

Breaking the close version ties with the rest of GNOME makes sense, but
not between Evo and EDS.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]