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
