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.
Agreed.
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. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature