On Fri, 2007-04-13 at 08:58 -0400, Jesse Keating wrote: > On Thursday 12 April 2007 21:05:14 Jason L Tibbitts III wrote: > > JLT> Well, I've had this exact discussion at least twice before and > > JLT> it's always come down to precisely the scheme I indicated. > > > > Some bits from my IRC logs: > > Seems we were in agreement with you here that something other than the date > could be used. > I agree. > I think Michael is just being difficult here. The date really doesn't help > because on Today I could check out a tag from 4 years ago and make it a > snapshot. No more meaning full than an svn revision number, in fact, LESS > meaning full. > Well... only because our guidelines are poorly expressing the use of date. They assume that the snapshot is being taken on HEAD. A minor revision that makes date meaningful in this context would be "When using snapshots, use the date that can be used to checkout the tree you are using from the VCS." > I'd fully support a draft to amend our guidelines around the snapshot stuff to > be more flexible for things other than date. > I would as well. Here are some things to consider: Goals: * Ability to reproduce the snapshot by checking it out from the upstream VCS. - Note that the primary place that this should be documented is not in the release tag but in a comment in the spec file. * Ability for end users to tell how recent the snapshot is. * Ability for end users to compare the version they have against other available versions. To me, the release tag after the rpmsortable integer is mostly for the end-user's benefit. So the latter two goals have more weight for me than the first. Issues and Non-Issues: * The tag does not need to be rpmsortable as there should be an integer in the release tag that takes precedence over this. * Each VCS has different ids. (Note, I'm ignoring tags as that's not something we can control for making snapshots of upstream projects.) - cvs only has dates for whole-tree checkouts. - svn has dates and revision numbers - git has hashes and dates and ?? - hg has revision numbers, (hash|revision id)(Not sure which) and dates and ?? - bzr has revision numbers, revision ids, and dates. * Distributed VCS's start to take us into realms in addition to naming. For instance, upstream may have a canonical stable branch/repo and a canonical development branch/repo. A snapshot taken from either branch could be represented by the same date or revision number (ie: they are meaningless without also specifying the branch/repo they come from). They would have different revids/hashes. Thoughts: Hashes and revisionids don't give very good information to the end user. Which is a newer snapshot: fa554dc or 65aad91? Revision numbers (a monotonically incrementing number) and dates seem to have about the same benefits and drawbacks to me. Dates are nice when used with HEAD checkouts because they tell the end user when an snapshot was taken at a glance. The packager has to work harder to get this benefit with historical checkouts (Figure out which date they want to grab from). Revision numbers and distributed VCS's could be slightly confusing to the end user as a revision number, although monotonically increasing on a particular branch, could go backwards if the package was rebased against a different tree but hopefully that wouldn't happen very often. I wouldn't be opposed to seeing revision numbers and/or dates used but revisionids and hashes should be banned. The canonical method of getting the snapshot should always be included in the spec file. Maybe something like this for prereleases: foo-1.0-0.2.20061005cvs bar-1.0-0.2.512svn baz-1.0-0.3.123bzr spam-1.0-0.3.171hg ham-1.0-0.4.20070121git -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
