On 2011-10-04 12:01, Toshio Kuratomi wrote: > 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? > > Also, since these are snapshots, a date in the upstream version field isn't > really that great either. Which branch is this from? Which repository > (in the case of DVCS)? With respect to a package's n-v-r, it doesn't matter which repository one's checkout of a given git commit comes from. One of git's main tenets is that a given hash refers to the same object in every repository in which it exists. Git commit hashes are also independent of the branches (if any) that point to them. With respect to recording source URLs, we already require commentary with a list of commands when people pull sources directly from version control. This will necessarily include a URL for the appropriate git repository. > Now do we want to put the git hash into the version field too? For the package's n-v-r alone to uniquely refer to a given commit it *must* contain the hash in a case such as this. To comply with packaging guidelines it also needs to contain a date and the string "git". This means it would need to contain 20111005git0123456. (I would also posit that the date is unnecessary, as it may not identify a unique commit, but that is a topic for another thread.) > If upstream is shipping releases where they put dates in as their versions > (as some fonts do) you might be able to make a case for this. In this case, > though, I don't think this is really a place to create our own release > string and put it in the field reserved for the upstream version. +1. I specifically suggest foo-0-1.20111005git0123456.fc16. Doing so will do a number of useful things: * A version of 0 is a clear signal that upstream does not use traditional version numbering. * A version of 0 provides a natural upgrade path if upstream later chooses to start using traditional version numbering. * Including the git hash makes the n-v-r alone refer to unique code. * It does not duplicate information. * It requires one to bend the fewest packaging guidelines. (One is only filling the Version field with an obvious placeholder) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
