release number when upstream *only* has git hashes?

[Ralf Corsepius]

On 10/04/2011 09:01 PM, Toshio Kuratomi wrote:
> On Tue, Oct 04, 2011 at 05:58:33PM +0200, Matej Cepl wrote:
>> On 4.10.2011 16:38, Toshio Kuratomi wrote:
>>> The date should not go there
>>> as you cannot tell if upstream will someday switch to an actual version
>>> string (which will then need an Epoch to upgrade cleanly from the date).
>>
>> That's your opinion or actually some rule?
It's common sense trying to reflect the priniciple of "least conflict", 
by avoiding potential NEVR conflicts with upstream and with 3rd party 
package repos.

>> Well, it depends on the
>> upstream circumstances, but if reasonable, I would think this is exactly
>> the situation where I would leave incrementing epoch number as an
>> available fallback and just go with dates as versions. Having software
>>
>> foo-0-0.<something very long and complicated>.fc16
>>
>> seems like something so ugly, that I wouldn't go there as a long term
>> solution.
>>
> 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?
IMO, without any doubt, the latter.

> Also, since these are snapshots, a date in the upstream version field isn't
> really that great either.  Which branch is this from?
Correct me if I'm wrong (I am far from being a git specialist), but I 
thought hashes were unique across branches?

>  Which repository (in
> the case of DVCS)?
IMO, similar to tarballs, which are required to be provided by the 
project's master repository, sources pulled from git need to originate 
from a project's public master repository.

>  Now do we want to put the git hash into the version
> field too?
Yes, because "git checkouts by date" are not sufficiently reliable to 
provide deterministic checkouts from git.

Ralf