Re: GEP-4 : Versioning and branching rules proposal

[Christian Rose <menthos menthos com>]

On Tue, 3 Sep 2002, Mark McLoughlin wrote:
> 	* 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.

I can think of one reason for incrementing the release number and
providing new versions of a package even though the code doesn't change --
new and updated translations. For packages that don't use translations
this of course doesn't apply, though.


> 	* 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.

While readable, they are usually bad as I understand it since they confuse
package managers. Strings in the release versions like "beta2" or "rc5"
will always be greater than real numbers in the string comparison, so
you'll end up with "2.2.0-rc5" > "2.2.0-1" and hence the new "gold"
package will not get installed over the "rc5" one when upgrading (that
is, without resorting to horrors like epochs).
At least, this is the reason that I heard of why strings in versions are
bad and should be avoided whenever possible, in favor of numbers.


Christian