Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
> 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).
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.
> > 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.
* git commit --amend
* any edit to an earlier commit
* reparenting, etc
* 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.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: