Re: [Evolution-hackers] Post-release version incrementing
Tor, It may not work out here, since the micro version is what we bump during release which is in sync with the GNOME Release micro version. I sent the idea to desktop-devel-list and gtk-devel-list instead, as mbarnes suggested. Let's see if anything comes out of it. Some people seem to like the idea, others don't see the point. In any case, if some change in convention happens, it presumably won't be in the current development cycle. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Post-release version incrementing
Tor, It may not work out here, since the micro version is what we bump during release which is in sync with the GNOME Release micro version. (Evolution 2.21.3 == GNOME 2.21.3) Matt, I'm not against it, if it benefits hackers. Personally I don't use 2 versions and so It doesn't matter much to me. If I don't hear any objections, I would be doing it during the 2.21.4 release and make trunk 2.21.5. -Srini. On Tue, 2007-12-11 at 03:29 +0200, Tor Lillqvist wrote: 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 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Post-release version incrementing
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
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
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
