[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SVN snapshot versioning

Neil Williams <linux@codehelp.co.uk> writes:

> On Tue, 23 Jan 2007 08:28:10 -0500
> "Roberto C. Sanchez" <roberto@connexer.com> wrote:
>> > The svn 'r' system is specifically designed to cope with this
>> > inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and
>> > inaccurate 'date' strings. Using a full UTC timestamp is even worse -
>> > far too messy.
>> >
>> > Looking up an 'r' number is as trivial as putting "svn r12314 project"
>> > into google. I really don't see what could possibly be easier.
>> >
>> Right.  However, I think we are rapidly approaching overkill in this
>> discussion.  How about this:
>>   * the version string includes the date
> I still see no reason for any package built from svn to include the
> date in any version string. It just makes it look like the DD doesn't
> understand how SVN differs from CVS.

This is in the eyes of the beholder. It does not really tell anything
about DDs/developers abilities. 

The date is very informative measure for live projects that are
packaged frequently. For the end user downloading these two packages
is very different:


The first thing is "techical" and has meaning for the upstream
and possibly for the DD packager only. The second one adds information
for the end user who downloads and installs the package to the system
telling how "fresh" this snapshot is. He does not care about the
VC system that the upstream uses.

The benefit of the latter is the best of both worlds:

- Exact indication of the point of revision (r145)
- Approximate information of the date when the snapshot was made
  The timestamp can also serve both DD and end user to remind
  if he needs to check for new updates.

The regular release syntax:


is in fact uninformative. The project may have disappeared long gone
and notbody would not know without digging up some more information.
Including date never hurts. It even helps sorting packages in correct
order easily.


Reply to: