Re: versioning macros

[Peter Simons]

Bastiaan Veelo writes:

 > [The] m4 source generated from XML does not contain any
 > documentation except a reference to the online archive.
 > That is not sufficient! We need at least a version number
 > and a copyright notice.

I've changed the process so that every macro header now also
contains a version ID. For an example:

  http://www.gnu.org/software/ac-archive/m4source/bnv_have_qt.m4

I am torn about the copyright notice. Repeating the GPL
synopsis AND the GPL-exception in every single file feels
weird. That is a LOT of redundancy, especially given the
fact that under the given URL you will find all the
information you'd ever want.


 > I'd prefer to have the documentation in there too.

Why do want this all redundancy? What's wrong about an URL?


Alexandre Duret-Lutz writes:

 > John should always use `cvs add -ko' when adding
 > third-party files to his tree.

Yes, I tend to agree with this view. Besides, like Bastiaan
mentioned, the release archive doesn't contain $Id$ strings
anyway; the version numbers are converted to something more
human-readable.

I really don't see how manually assigned version numbers
would have any advantage. When two people modify the same
macro and both bump the version number manually, then you
still have a clash, you still depend on CVS (or whatever you
use) to sort that collision out. So why not use the
version information CVS provides?


 > In Libtool, Automake, Gnulib, Gettext, many macros have a
 > `#serial NNN' line that is updated by hand. Some tools
 > use it when updating macros.

My personal favorite is the approach Monotone [1] uses. It
doesn't have any concept of sequential version numbers at
all. Instead, any given version is identified by the SHA1
hash of all contents. That guarantees two people talk about
the same thing when they say "version x", only they say
"version b553e051c0f5a9df2e5fbd7b4199d14d39ab1b43".

It's not necessarily a good idea for our purposes, though, I
admit. ;-)


 > I have only briefly discussed this with Akim, and one
 > idea was to use something like
 >
 >   m4_define([serial], [15])
 >
 > [...]

I like that idea. A macro being (potentially) aware of its
own version is always nice to have, and that approach
supports that.

Peter


[1] http://www.venge.net/monotone/