release number when upstream *only* has git hashes?

[Toshio Kuratomi]

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

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)?  Now do we want to put the git hash into the version
field too?

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.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111004/6f7db990/attachment.bin