Re: Policy: Versioning Macros In The Archive

[Tom Howard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Peter,

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

After re-reading what you wrote, I know understand that bumping the
version for the author was in term of bumping it in ac-archive, not
for the actual authors copy.

I think we both agree that increasing the version number when a macro
is patched in definitely required.

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

Sweet.

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

Actually in that case it makes no difference (in terms of patching)
what type of version is used.

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

Well, I can see your sold on date stamps.  In that case, can we name
them correctly?  i.e. use @last_modified or @datestamp, rather than
version.  The only reason I suggest this is most people don't expect a
version to be a datestamp, hence (working on the principle of least
surprise) we shouldn't call it @version

>> BTW, I'm already thinking of adding `make patch` to
>> ax_cvs, which could be very handy :D
>
> What exactly would that target do?

It would do a cvs update, then a cvs diff (I can't remember the patch
compatible flags off the top of my head) and put the result in
something like $PACKAGE-$VERSION-$USER-$DATE.patch.  So If I created a
patch for ac-archive, it would create a file called

ac-archive-X.Y.Z-thoward-20050126.patch

Which I could then upload as a submission.  With this kind of feature,
the submission process (for both new macros and fixes) could become:

1. grab the cvs
2. do your changes
3. run make patch
4. send us the patch

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

Agreed, but if new submissions are made with `make patch` as well,
then no-one should be sending plain m4 files, ever.  Also, just
because something is banned, doesn't mean it won't happen.

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

With a version number, at least I can indicate the severity of the
change form version to version.  For small changes, I would only
update the point number, for significant changes I would update the
major number.  How can I represent that with a datestamp?

Well, the only hint I have left for you is that almost everywhere else
uses version numbers, not version datestamps.  They could all be
wrong, but I doubt it.

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9w98w1G4ZUM7KZoRAnpUAKCdQueoDfGvC4WZNVu1HRY8QDwNFACglXKX
/FsIETkFg5CZIYeb5hkztXs=
=m826
-----END PGP SIGNATURE-----

tomhoward.vcf
Description: Vcard