[Evolution-hackers] Post-release version incrementing

2007-12-10 Thread Matthew Barnes
Just a thought:

I and I'm sure many of the Evolution developers find themselves
frequently switching between Subversion builds and official releases as
part of our daily work routine, and sometimes I get confused about what
I'm running, especially when bonobo-activatation-server is part of the
equation.

I notice we've been doing pre-release version incrementing (bumping the
version number just before a release) for at least as long as I've been
involved with Evolution.  I was wondering if the team would be open to
switching to post-release version incrementing (bumping the version
number just after a release).

The GNOME Live! page [1] goes a bit into why post-release incrementing
is preferred.  In particular:

  Most everybody used to bump the version number just before the
   release but we've found that bumping just after the release works
   better because people can explicitly require the version number in
   HEAD; i.e. if the last release of gtk+ was 2.5.1 and new API is
   added, its nice for any module that uses that API to immediately
   require gtk+ 2.5.2.

Mainly I would like to see the Evolution version show up as (currently)
2.21.3 when I'm running the latest release and 2.21.4 when I'm running
from HEAD, just as a sanity check.

Not a huge issue, but for me it would be a time saver.

Matthew Barnes

[1] http://live.gnome.org/MaintainersCorner/Releasing

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Post-release version incrementing

2007-12-10 Thread Tor Lillqvist
 I notice we've been doing pre-release version incrementing 
 [...]
 I was wondering if the team would be open to switching to post-release 
 version incrementing 

May I suggest a third, in my opinion superior, way: Both.

That's what cairo uses, see
http://cairographics.org/manual/cairo-Version-Information.html . The
micro version number is even in released tarballs, and odd
inbetween. The even number never exists in SVN. The micro number is
bumped by the person doing a release, and then bumped again and
committed after the tarball has been built. Thus there cannot be any
confusion between official released versions and builds from SVN at
least as far as version numbers are concerned.

--tml

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Post-release version incrementing

2007-12-10 Thread Matthew Barnes
On Tue, 2007-12-11 at 03:29 +0200, Tor Lillqvist wrote:
 May I suggest a third, in my opinion superior, way: Both.
 
 That's what cairo uses, see
 http://cairographics.org/manual/cairo-Version-Information.html . The
 micro version number is even in released tarballs, and odd
 inbetween. The even number never exists in SVN. The micro number is
 bumped by the person doing a release, and then bumped again and
 committed after the tarball has been built. Thus there cannot be any
 confusion between official released versions and builds from SVN at
 least as far as version numbers are concerned.

While that sounds like a sensible policy, Evolution follows GNOME's
release schedule and version numbering [1]. So that would have to be
enacted for all GNOME components, and that discussion is better suited
for desktop-devel-list.

Matthew Barnes


[1] http://live.gnome.org/TwoPointTwentyone

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers