release number when upstream *only* has git hashes?

[Garrett Holmstrom]

On 2011-10-04 12:01, Toshio Kuratomi wrote:
> So my solyution:
> foo-0-1.20110120git.fc16 vs
>
> Your solution:
> foo-20110120-1.20110120git.fc16
>
> (Since it's a snapshot, the date has to go into the release string anyway)
> Which is uglier?
>
> Also, since these are snapshots, a date in the upstream version field isn't
> really that great either.  Which branch is this from?  Which repository
> (in the case of DVCS)?

With respect to a package's n-v-r, it doesn't matter which repository 
one's checkout of a given git commit comes from.  One of git's main 
tenets is that a given hash refers to the same object in every 
repository in which it exists.  Git commit hashes are also independent 
of the branches (if any) that point to them.

With respect to recording source URLs, we already require commentary 
with a list of commands when people pull sources directly from version 
control.  This will necessarily include a URL for the appropriate git 
repository.

> Now do we want to put the git hash into the version field too?

For the package's n-v-r alone to uniquely refer to a given commit it 
*must* contain the hash in a case such as this.  To comply with 
packaging guidelines it also needs to contain a date and the string 
"git".  This means it would need to contain 20111005git0123456.

(I would also posit that the date is unnecessary, as it may not identify 
a unique commit, but that is a topic for another thread.)

> If upstream is shipping releases where they put dates in as their versions
> (as some fonts do) you might be able to make a case for this.  In this case,
> though, I don't think this is really a place to create our own release
> string and put it in the field reserved for the upstream version.

+1.  I specifically suggest foo-0-1.20111005git0123456.fc16.  Doing so 
will do a number of useful things:

* A version of 0 is a clear signal that upstream does not use 
traditional version numbering.

* A version of 0 provides a natural upgrade path if upstream later 
chooses to start using traditional version numbering.

* Including the git hash makes the n-v-r alone refer to unique code.

* It does not duplicate information.

* It requires one to bend the fewest packaging guidelines.  (One is only 
filling the Version field with an obvious placeholder)