Re: versioning macros

[Bastiaan Veelo]

Peter Simons wrote:

> 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
>
>  

Good.

> 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.
>  

No offence, but I am surprised to hear these words from a GNU guy. I 
don't need the complete license text embedded in the macro, but a short 
notice of who owns the copyright and where to find the license text is a 
minimum. Because macro's can be downloaded at the click of a button 
without being packaged or anything, and because they then become part of 
X different project trees with all their own copyright holders and 
possibly different licenses, this information needs to follow the macro. 
In fact you have no license to strip the name of the owner and the 
license from the file, as is happening now...!

> > I'd prefer to have the documentation in there too.
>
> Why do want this all redundancy? What's wrong about an URL?
>  

Not everybody is online all the time. The documentation need not be 
inline, if it can be made part of the macro installation. A man-page 
would be nice, I think. But inline would be the most straight forward.

> 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.
>  

Wait a minute, I just discovered that the distributed macros in the 
legacy tree also are generated! When did that change? And why? sf.net 
still distributes the pristine sources, and I think it should be that 
way. Now the copyright problem applies to the legacy tree as well, and 
it is confusing that two files with the same name from the same site 
have different contents.
I am not happy with generated files, I'd rather work with the same file 
in my projects and against the macro archive, and know that people that 
use the macro see the same file as I do. That is why I prefer a manually 
maintained release number.

> 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?
>  

That would be fine if there is only one repository, and files are not 
committed to other repositories without the -ko flag. But I have my 
macro in my own development tree, and there may be many commits there 
before it is ready for release. Then I commit it to the archive. I want 
the version numbers to be the same then, for identical files in 
different repositories. The version number should depend on the number 
of changes made to the file, not the number of commits to a particular 
repository. So the version (or release number) is something I want to be 
in control of, and it is going to make jups in the archive.

> > 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.
>  
That would be good. Baybe this could support versioned dependency rules 
in the future?

Best regards,
Bastiaan.