Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 07:21 -0400, Paul Smith wrote: > Not being familiar with Evo development I'm not sure how feasible it is, > but ideally part of the change in release cycle would mean divorce from > the Gnome version lockstep, and Evo being able to build against multiple > versions of Gnome. If Evo were changed to be more of a stand-alone > utility (at least optionally), rather than being bundled with Gnome, > that would be (IMO) a good thing for users. I've already come to regard Evolution as a GTK+ application rather than a GNOME application. While we do have some (optional) desktop-specific integration for GNOME and Unity, I for one do most of my development on XFCE nowadays. Evolution has also been buildable on multiple GNOME releases for awhile now. For the past several years I've tried to ensure the development branch of Evolution and co. remains buildable on the latest *stable* GNOME development platform, such that our major releases are actually developed for the previous GNOME release. Evolution 3.8, for example, builds on both GNOME 3.8 and GNOME 3.6. I think targeting the latest stable development platform strikes a good balance between utilizing new advancements in the platform and keeping a safe distance from the chaos at the bleeding edge. I don't foresee that policy changing as we transition to a longer release cycle. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Mon, 2013-07-29 at 01:26 +0200, Tobias Mueller wrote: > Hm. I'm wondering whether this is a problem for the rest of GNOME, too. > Do the arguments brought up in this thread apply to Evolution (and > friends) only? If no: Would the rest of GNOME also benefit from a > different release schedule? If yes: Why would that be? The arguments on > favour of a longer cycle seem to be very generic to me. It's difficult to speak to GNOME as a whole because -- GNOME OS visions notwithstanding -- GNOME is a diverse collection of independent projects of different sizes, levels of maturity, "activeness" and agendas. Different projects of different sizes have different needs. I'd caution against generalizing from one example. The arguments brought up here may not be unique to Evolution, but they're based on observations of how well Evolution development policies are serving the Evolution community. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Hi. On Wed, Jul 24, 2013 at 07:21:46AM -0400, Paul Smith wrote: > On Wed, 2013-07-24 at 10:58 +0100, David Woodhouse wrote: > > 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. > > I agree with David. My main frustration with Evo right now is that I'm > always a release behind because my distribution appears to be > chronically one Gnome release back (I understand this is due to my > distribution and not the responsibility of the developers), for whatever > reason. That means I was stuck on 3.4 until May (which was bad as there > were numerous problems with 3.4), and will be using 3.6 for most of the > rest of the year. > Hm. I'm wondering whether this is a problem for the rest of GNOME, too. Do the arguments brought up in this thread apply to Evolution (and friends) only? If no: Would the rest of GNOME also benefit from a different release schedule? If yes: Why would that be? The arguments on favour of a longer cycle seem to be very generic to me. Cheers, Tobi ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Fri, 2013-07-26 at 07:38 -0400, Matthew Barnes wrote: > It seems like we have a general consensus among developers in favor of a > longer release cycle. Next week I think I'll pitch the idea to the user > list just to get a sense of the response. Just to follow up, I posted this to the user list over the weekend: https://mail.gnome.org/archives/evolution-list/2013-July/msg00162.html Too early to draw conclusions from the response, but so far so good. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Fri, 2013-07-26 at 07:38 -0400, Matthew Barnes wrote: > > * I think our policy toward stable branch maintenance could be a little > more relaxed during the first half of a release cycle in terms of what > we allow in. I don't know what that means exactly for us yet, but I > have observed RHEL updates do sometimes include new features. Maybe > enterprise policies could be a rough guide until we find our footing. Well, you lot haven't *actually* shouted at me very much for some of the stuff I've added in stable branches. I get more pushback from the translators if I have to add new strings, than I did for the whole of the mspack and GAL rework which landed in 3.8 for example. I'm happy enough with that :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, 2013-07-23 at 10:10 -0400, Matthew Barnes wrote: > 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? It seems like we have a general consensus among developers in favor of a longer release cycle. Next week I think I'll pitch the idea to the user list just to get a sense of the response. To clarify a few points: * I should have been more explicit but I did mean ALL our modules, not just Evolution. EWS, MAPI, and especially E-D-S. I think E-D-S is more in need of a longer support cycle than Evolution itself, since a lot of our stable branch maintenance focuses on the infrastructure and backends provided by E-D-S. IMAP, CalDAV, LDAP, etc. * I see the wisdom in Milan's suggestion of sticking to our current version numbering, but just slowing it down. It might cause some confusion initially, but once we jump ahead of the GNOME release numbers we can't go back. So "Evolution 4.0" is off the table. I do still find the year-based numbering appealing: Evolution 2014.x, etc., since there's no major version number to set false expectations for a project that does incremental improvements. And users would be more aware of how old of a release they're using, instead of it being some arbitrary number. And it removes the idiotic "lesser version == less mature" mentality when comparing two unrelated projects. I just can't figure out what to call the development snapshots. * I think our policy toward stable branch maintenance could be a little more relaxed during the first half of a release cycle in terms of what we allow in. I don't know what that means exactly for us yet, but I have observed RHEL updates do sometimes include new features. Maybe enterprise policies could be a rough guide until we find our footing. * I like Milan's idea of publishing our own release schedule as an .ics file, as in http://www.gnome.org/start/unstable/schedule.ics. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Thu, 2013-07-25 at 06:42 +0200, Milan Crha wrote: > ... even it brings more work to us. For a good reason, of course. By the way, it also means that any so-called white-space cleanups, which I always understood as a one-time job, not a multiple-times-per-releases job, should either stop completely (we have our code under control, do we not? [1]) or be done only once, just before the major release. I was just beaten by this when applying a patch from master to gnome-3-8, it was quite painful and discouraging to apply the patch by hand. Bye, Milan [1] The "script" introduces coding style bugs too, which should be fixed. I noticed multiple times that it uses 8 spaces instead of tabs for function parameters indentation, but the evolution code uses tabs for indentation. It doesn't make me laugh when I see a "white-space cleanup" change being mostly about this nonsense in the code I just wrote and made sure I follow the coding style guide for evolution code. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, 2013-07-23 at 10:10 -0400, Matthew Barnes wrote: > Increasingly I'm feeling like the traditional 6-month release cycle is > just too short for Evolution. Hi, I'm replying slightly later, I was thinking of this a bit. Generally I agree, I also feel like the 6-month release cycle is too short for any extensive work. 12-month might be better, even it brings more work to us. For a good reason, of course. > * 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). I would not bump the version, let's just slow down. One cannot do major rewrites all the time, the dust should settle one day, and then we might get back to sync with GNOME releases, and possibly also version. The GtkHTML version is the example for me, when we couldn't do that, when other evolution products were version-synced with GNOME version, for easier recognition which GNOME version this is supposed to work on. > * 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. I can imagine a simple .ics file on http://projects.gnome.org/evolution page with the release schedule, like the one for GNOME releases exists :) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, Jul 24, 2013 at 3:28 PM, David Woodhouse wrote: > 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. It is my wish, we could decouple EDS & Evolution releases to start building API/ABI stability into EDS. I don't have strong objects to EDS having yearly releases. Im not saying that we wont/cant' to backporting fixes and re-releasing for minor/micro releases. We should be able to go back at least 2 GNOME releases. This is required kind of required if you want to avoid 'adapting to 3.6 EDS' like commits in EWS/LibreOffice/SyncEvolution/* -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Hi Fabiano, On Wed, Jul 24, 2013 at 6:29 AM, Fabiano Fidêncio wrote: > Srini, > > >> 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. > > Could I ask you why? > If you check our git's activity you will see that the most part of > bugs we are fixing are touching both in Evolution as in EDS. > I really cannot imagine these two parts not walking together. I know how tight the development is. Infact, in my watch, we added a configure check that mandates same minor & micro version. But IMHO this model should change for good. It kind of brought lot of flexibility for introducing breakages because we know Evolution would work with only the right version of EDS well but we kind get into a model of ignoring the apps that would depend on EDS. All along we (Evolution/EDS hackers) were blamed for breaking API/ABI. Im not support this following statement, but there was a time, when you can just build evolution and not use latest EDS/Gtk/other platform bits on atleast 2 older GNOME releases. I may not ask for this, but atleast we should have EDS decoupled from Evolution releases to let it survive/develop as a platform on its own. Some might argue that having a yearly releases will give longer API/ABI stability, but again coupling EDS & Evolution will let us into more breakages. My point for this was not about the duration, but about decoupling the EDS & Evolution releases to plan/avoid any API/ABI (re)designs for EDS. This is my thought, and some may support it but a lot might oppose it ;-). Thanks, -Srini. > > Best Regards, > -- > Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 10:58 +0100, David Woodhouse wrote: > 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. I agree with David. My main frustration with Evo right now is that I'm always a release behind because my distribution appears to be chronically one Gnome release back (I understand this is due to my distribution and not the responsibility of the developers), for whatever reason. That means I was stuck on 3.4 until May (which was bad as there were numerous problems with 3.4), and will be using 3.6 for most of the rest of the year. If the distributors and the Evo release cycle don't line up nicely you could be working with an Evolution that's more than 18 months old (assuming a 6 month distro release cycle; some distros are longer than that) before you get to the next version. Not being familiar with Evo development I'm not sure how feasible it is, but ideally part of the change in release cycle would mean divorce from the Gnome version lockstep, and Evo being able to build against multiple versions of Gnome. If Evo were changed to be more of a stand-alone utility (at least optionally), rather than being bundled with Gnome, that would be (IMO) a good thing for users. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 10:59 +0100, David Woodhouse wrote: > On Wed, 2013-07-24 at 02:54 +0200, Fabiano Fidêncio wrote: > > > > 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.. > > Am I the only one who fixes bugs and implements features on the > gnome-3-8 branch, then commits, cherry-picks that to master, and *then* > cherry-picks it back to gnome-3-8 (with the -x option) to make it look > like it happened in master first? Hi, I'd say "double yes": 1) yes, I do develop new things in master first, then backport to stable branch (it's sometimes only about applying, sometimes real backport) 2) yes, most likely because stable branches are feature-frozen (plus couple more freezes), thus you violate a policy by doing new features there. :) Of course, one may define what a new feature is in the first place. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 02:54 +0200, Fabiano Fidêncio wrote: > > 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.. Am I the only one who fixes bugs and implements features on the gnome-3-8 branch, then commits, cherry-picks that to master, and *then* cherry-picks it back to gnome-3-8 (with the -x option) to make it look like it happened in master first? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
> On Tue, Jul 23, 2013 at 7:40 PM, Matthew Barnes 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 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Srini, > 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. Could I ask you why? If you check our git's activity you will see that the most part of bugs we are fixing are touching both in Evolution as in EDS. I really cannot imagine these two parts not walking together. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Matthew, On Tue, Jul 23, 2013 at 4:10 PM, Matthew Barnes 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, Jul 23, 2013 at 7:40 PM, Matthew Barnes 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. I like the idea very much and had similar plans before, but never went forward with it before. > > 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. > 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. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, Jul 23, 2013 at 4:43 PM, Sasa Ostrouska wrote: > > > > On Tue, Jul 23, 2013 at 4:10 PM, Matthew Barnes 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 >> >> > More as a user than as a dev, but yes, I fully agree with you. Evolution > is an important piece of software in my business. > I have been using 2.26.3 up to half yer ago, as upgrading all the time in > terms of business is really a pain in the ass and > not worth for the few new features you can get. > > Another thing is that as you say it is important to have a stable and rock > solid application. This is something you can get > with good checking and testing. Of course this needs time and not only. > > So if my voice can have some impact, I'm all for a longer release cycle > and well done development. Things done in a hurry > usually are not good or well done. > > Especially when we talk about free software where contributors have their > real life to take care of. > > Rgds > Saxa > > >> ___ >> evolution-hackers mailing list >> evolution-hackers@gnome.org >> To change your list options or unsubscribe, visit ... >> https://mail.gnome.org/mailman/listinfo/evolution-hackers >> > > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
