[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: limits for package name and version (MBF alert: ... .deb filenames)

On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
> On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
> > I would like to see policy forbid the use of commit hashes in versions.
> > They aren't ordered, and the information about exactly which commit the
> > snapshot was can be included in the changelog.
> 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).

> A small portion of the hash is there only to disambiguate potential
> branches, ordering is provided by the number of commits:
> 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it,
> from a branch whose head's hash starts with 1143071.
> If I take revision 282 and apply patch X, while you take the same revision
> but apply patch Y instead, we both would have the same version number if
> hash is not included.

But it is not possible for a branch head to be in two different
positions at different times which 'git describe' will distinguish only
by the hash, unless it is rebased.

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


Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: