Ben Hutchings dijo [Sun, Apr 24, 2011 at 04:54:46AM +0100]: > > If you use "git describe", removing hashes is a bad idea. > > > > They are needed to identify the version. Version numbers that are not > > unique are worthless. > > If versions are not ordered without the inclusion of a commit hash, they > are not ordered *with* it (except by chance).
However, the use case described by others in this thread means the hash is the least significant part of the version - Yes, it lengthens the version number with no obvious meaning (and the reason for this thread is precisely limiting the version number length), but it contains important information in order to get to a given precise source. > > You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my > > commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you > > that. > [...] > > Last time I looked, policy required upstream source to be provided as > tarballs, not VCS references. Well, many authors don't ship tarballs but refer to points in their development history. I am maintaining the Githubredir¹ service, even though from the beginning I knew it was a limited and probably near-sighted solution - But yes, I'm limiting its results to tags in the project history, and I'm expecting the tags to be version numbers ordered in a sane fashion. Anyway - Summing up what I'm saying here, tags have a clear meaning: A point where upstream wants us to base our efforts at, mid-devel-cycle breakage should be at a minimum. So, instead of basing our packages off arbitrary commit hashes, why not basing them off tags? I do not believe it is unreasonable to request upstreams to do some tagging... ¹ http://githubredir.debian.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425175017.gj1...@gwolf.org
