[Fedora-packaging] Using of date in snapshot versions

Toshio Kuratomi a.badger at gmail.com
Fri Apr 13 20:58:59 UTC 2007


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070413/dbc4b053/attachment.sig>


More information about the Fedora-packaging mailing list