release number when upstream *only* has git hashes?

[Toshio Kuratomi]

On Tue, Oct 04, 2011 at 09:13:46AM +0200, Ralf Corsepius wrote:
> On 10/04/2011 08:04 AM, Eric Smith wrote:
> > I wrote:
> >> What should I use for the release number in a spec when upstream does
> >> not have releases, and *only* has git hashes?  It's not a prerelease
> >> since it is not clear that there will ever be any official release.
> >
> > I meant "version number", not "release number".
> 
> OK, this makes a big difference.
> 
> If the project doesn't use an internal version number, I'd use "0" and 
> never increment it.
> 
>   If the project has some internal version number (e.g. most autoconf 
> based project have one, even if they don't have a release tarball), I'd 
> use this one.
> 
+1

> > I imagine that the
> > release number should still be 0.1.<yyyymmdd>git<hashprefix>.
> 
> I'd use "0.<yyyymmdd>git<hash>.%{?dist}" or similar.
> 
Just to clarify -- this release string goes hand-in-hand with using 0 as the
version string.  We're assuming that upstream will never release a version
0 and therefore the post-release snapshot form is better than the
pre-release form.

> The only points that count are
> - Do not introduce (inofficial) version numbers (Upstream is the only 
> authority to set them), because they may cause problems, should upstream 
> once start to use version numbers.
> 
> - Within a "version" all release tags must be steadily incrementable and 
> should provide sufficient human readable information to allow others to 
> verify the tarball.
> 
+1

> > Or for
> > this case, should the date and git hash go into the version?
> 
> I'd recommend doing so, because this helps verifying/regenerating the 
> tarball.
> 
I think you read this wrong or missed a negative in your reply.  For me,
I would *not* recommend putting the date and git hash into the version.
(The release, yes;  version, no).  The hash definitely should not go there
because it cannot be depended on to increment.  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).

-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/f9b026ba/attachment.bin