Re: release number when upstream *only* has git hashes?
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