Re: [Evolution-hackers] Reconsidering our release cycle

[Matthew Barnes <mbarnes redhat com>]

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