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