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

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

On Mon, Apr 25, 2011 at 10:29:53PM +0100, Ben Hutchings wrote:
> On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote:
> > On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
> > > If versions are not ordered without the inclusion of a commit hash, they
> > > are not ordered *with* it (except by chance).
> > 
> > Remember that version numbers have two purposes:
> > 1. ordering
> > 2. uniquely referencing a snapshot of source (blessed as a release or not)
> > 
> > I'd call 2. more important than 1.
> It's not very important in the Debian archive.

Telling someone "the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was" is not very useful.

> > > 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.
> > * resetting to another version of the branch that has the same commit count
> > * two developers or one developer with two machines or directories
> > * many, many other ways
> >
> > Mere count of commits is pretty worthless in a distributed system.
> If your upstream is pulling such tricks then you cannot use this type of
> version *with or without* the hash, because it will not be ordered
> properly.  You would have to use a date/timestamp.

Eh?  It is exactly why the hash is there!

No matter how many commits were done at a particular date, and whether the
commit was cherry-picked, rebased or tossed around in other ways, a hash
will let you tell which exactly version it is.

A date or timestamp will not.

1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.

Attachment: signature.asc
Description: Digital signature

Reply to: