Re: Policy: Versioning Macros In The Archive

[Peter Simons]

Braden McDaniel writes:

 >> The problem is that this additional information has no
 >> relevance for the archive.

 > Well, I'd argue that's not a release version number;
 > that's a CVS version number. It was never a good idea to
 > put that in @version for precisely the reasons you note,
 > and I have not done that for quite some time. I have,
 > however, included a release version number.

Right, but that release information has no relevance for the
archive. When someone else sends in a patch for your macro
and we can't reach you to check back (that _has_ happened in
the past), then we have no way of bumping that release
version number of yours. So exactly did it say in the first
place?

In terms of the archive, the version number 1.23 has no
meaning -- the date of the last modification has.

I would argue that submissions should be checked into CVS in
verbatim (with the @version line left as it is), and _then_
we'd run axlint to canonize it, so that the "loss of
information" is documented in the macro's CVS history. That
would be good practice.


 >> The only reliable version information is the date stamp of
 >> the last modification _in the archive_.

 > If you confine the options to [CVS ID or date], then yes.
 > But it seems to me the problem is only with the CVS ID,
 > and realistically there are more options than just those
 > two.

I hope you haven't misunderstood me here. We are discussing
different two points:

 (1) Are date strings a good version ID for the archive?

 (2) Should the archive carry additional version information
     even though it doesn't use them.

My comment was made in regard to (2), as in: The archive
doesn't care about auxiliary annotation in @version, we just
want the date stamp, nothing else.

Your answer seems to be directed at (1), though. Are you
unconvinced that "date of last modification" makes a good
version for an archive entry? What other solution would you
propose?


 > How about leave @version alone and introduce
 > @last_modified (or somesuch) to hold this date?

It would be technically possible, but I don't see why it
would be a good idea. If the submitter really, really wants
to tell the world what version he thought the macro had when
he submitted it, then he can put it into the m4 source.
Adding yet another tag to the growing collection so that
@version can serve that purpose feels odd.

Besides, having both @last_modified _and_ @version in the
same file would probably confuse the hell out of the user. I
would be confused.

Peter