Re: Policy: Versioning Macros In The Archive

[Peter Simons]

Tom Howard writes:

 > Hmm, I'm not sure we actually disagree.

We seem to agree on the assumptions but not on the
conclusion. :-)


 >> Modifications to macros distributed by the Archive MUST be
 >> submitted as a "diff" suitable for use with patch(1).
 >> Patches that do not modify the @version tag MUST NOT be
 >> accepted.

 > Agreed, but the version test must be slightly more
 > complex. Rather than just checking for a difference in
 > the version tag, the version patch must be greater than
 > the version in the original.

The good news is that patch(1) will fail if the line is
_different_. It doesn't matter how it differs. So we really
can use any kind of @version tag we want, as long as it is
different every time -- and date stamps serve this purpose
exceptionally well.

I concede, though, that it would be very nice if the version
were actually greater if it was newer, there should be a
notion of "increasing" the version. Which, as it happens,
date stamps do just fine, too.


 > BTW, I'm already thinking of adding `make patch` to
 > ax_cvs, which could be very handy :D

What exactly would that target do?


 >> A resubmission of the complete file MAY be accepted from
 >> the principal author of the macro, but that practice is
 >> generally discouraged.

 > If I get `make patch` implemented, can we ban it all
 > together?

I think it is unrealistic to ban it altogether. If someone
has just submitted a macro, than submits a new version a day
later, it is perfectly alright to just copy the file in,
IMHO. It's not like anybody could be sued for breaking
policy anyway. ;-)


 > So does that mean you agree that using a date as a
 > version number is bad as a date version number will
 > almost always be different?

No, I think that a date stamp is great exactly because of
that property.

Peter