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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
