On Tue, 23 Jan 2007 09:56:28 +0100 Stefano Zacchiroli <zack@debian.org> wrote: > On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: > > Why bother with the date? 2.1~svn-r91 seems much more concise and > > has the same information, really. > > Though you're right that the information is the same, a date is > meaningful in spite of the knowledge of the revision control system > (subversion in this case). The same can't be said for the SVN revision > number. As commented elsewhere, normal release numbers do not have any date component and you've still got the problem that multiple svn commits are frequently made on the same day. The date, in this context, is just misleading and would need to be a full UTC timestamp to have any real meaning. The revision number is far more precise and just like a normal 1:2.3.4-5 release string, you would need to refer to the upstream website(s) to determine the date of the release. The advantage of just using the svn 'r' number is that it makes this information available precisely and without duplication. Looking up that 'r' number not only tells you the date - just as looking up a normal release string would do - it also uniquely identifies the point at which the upstream code was packaged - again, just as a release string is intended to do. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpz57DF_rxXG.pgp
Description: PGP signature