release number when upstream *only* has git hashes?

[Toshio Kuratomi]

On Tue, Oct 04, 2011 at 09:32:28PM -0700, Garrett Holmstrom wrote:
> 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.
> 

To clarify what I meant since it seems both you and Ralf read this
differently than I intended:

I'm starting by saying that using date alone is not sufficient to identify
the checkout and therefore should not be used in the upstream Version:
field.  I then put forward what I think people's next candidate would be:
the git hash.  At that point, (I thought this but perhaps didn't write it
out) you run into the problem where the git hash does not increment and
therefore you potentially need to bump epoch with every release.  So the git
hash is also not a good candidate for the upstream version field.

> (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.)
> 
The rationale is that the Release field is documenting for two audiences.
The important audience is the end user.  The end user either doesn't know or
doesn't want to go through the trouble of verifying what version of software
a git hash refers to.  They just want to be able to say that a bug was fixed
on January 1, 2011 or that Ubuntu has the 0.11 release from February 2,
2012 and then compare that to the Fedora package.  The second audience is
other packagers and developers of the software.  These people may want to
grab the exact snapshot of the software from upstream.  If they don't want
to open up the spec file to see our comments on how to get the snapshot
(maybe they're actually Ubuntu devs and don't know how to get at that
information easily) the release field may optionally provide this
information.

-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/20111005/757a4f40/attachment.bin