release number when upstream *only* has git hashes?

[Ralf Corsepius]

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.

> I imagine that the
> release number should still be 0.1.<yyyymmdd>git<hashprefix>.

I'd use "0.<yyyymmdd>git<hash>.%{?dist}" or similar.

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.

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

On a wider scope, I'd however question if such a project is mature and 
stable enough and maintained well enough to be included into Fedora. 
Many projects, which do not release tarballs in longer terms often prove 
to be poorly upstream maintained and to be problematic when it comes to 
inclusion into a distro (e.g. lack of stable APIs, SONAME etc).

Ralf