[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Policy: Versioning Macros In The Archive
From: |
Tom Howard |
Subject: |
Re: Policy: Versioning Macros In The Archive |
Date: |
Tue, 25 Jan 2005 14:53:25 +1100 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
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
- Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Tom Howard, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/24
- Re: Policy: Versioning Macros In The Archive,
Tom Howard <=
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/25
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/26