release number when upstream *only* has git hashes?
rc040203 at freenet.de
Wed Oct 5 04:53:50 UTC 2011
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
>> 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
> So my solyution:
> foo-0-1.20110120git.fc16 vs
> Your solution:
> (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.
More information about the devel