Re: Policy: Versioning Macros In The Archive

[Tom Howard]

Hi Peter,

>  > We shouldn't worry about bumping the version number for
>  > the author.
>
> I disagree. This version information is _our_ version. That
> is the version the Archive provides.

Hmm, I'm not sure we actually disagree.  I also think the version it the
ac-archive version number for that macro, hence why we shouldn't care
what version the original author has.

> We cannot rely on the
> initial author to take care of that, because macros may be
> (and will be) modified by other people too. Therefore, the
> _Archive_ has authoritative version information, not the
> initial submitter.

I agree completely.

>  > [Just] say someone submits a patch for one of my macros
>  > and I'm un-contactable (for whatever reason) or don't
>  > notice. When I make some other change and submit an
>  > update, if we are using version numbers, a version number
>  > conflict will be noticed [...].
>
> Excellent example! Thanks a lot, this gives rise to a
> wonderfully obvious addition to the policy:
>
>   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.  Why?  What if two
patches are submitted against ax_extra_dist and I don't notice, the
version is now 1.2 and then I submit a patch with a version of 1.1?  I
don't know patch well enough to know if it will cope with this and
report an error.

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

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

> Rationale:
>
> By applying only patches -- and only patches that modify the
> @version tag, that is -- it can be guaranteed that the
> modification was written for the version of the macro that
> the Archive currently distributes. The practice rules out
> unnoticed conflicts between independent submitters.

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?

Cheers,

--
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A

tomhoward.vcf
Description: Vcard

signature.asc
Description: OpenPGP digital signature