Re: GEP-4 : Versioning and branching rules proposal

[Mark McLoughlin <mark skynet ie>]

Hi Frederic,
	I agree with the intent of this proposal (which isn't well
documented in the GEP, but should be) but I have quite a few problems
with the details:

	* The 'rules' are too inflexible. For example, if this was
adopted and I went to apply the rules to libIDL I would have to create
a gnome-2-0 branch and on HEAD change the version from 0.8.0 to
2.1.0.0. Then very regularily after that I would have to keep
incrementing the version number, even though its unlikely that a
single useful change has been made. Users would continually downloaded
the new packages, but for nothing. Lots of hassle and for what? In
this case (granted its an extreme case, I think in the last year there
has only been asingle significant code change) what does this proposal
achieve.

	* There are quite a few packages in the platform that aren't
really specific to GNOME. Should they have to conform to these rules.
If not, where do we draw the line of modules that should and modules
that shouldn't. Could we have a compromise set of rules for these
modules. E.g. that they tag the module after every release.

	* The proposal states that when a GNOME version is released
that the module should branch. This shouldn't be set in stone. Some
modules may wish to branch before that - e.g. when the feature freeze
starts - or some modules may not wish to branch until a few more micor
releases are done and some modules may never need to branch at all.

	* No mention is made of micro reelase branches e.g.
gnome-2-0-0.

	* No mention is made of tagging a module after every release
e.g. GWACKY_APP_2_1_5_32

	* How about versions like '2.2.0-rc5'. I've never used them,
but it does strike me that they are more readable and readily
identifiable.

Good Luck,
Mark.

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers