[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: |
Wed, 26 Jan 2005 14:33:16 +1100 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
-----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
- 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, 2005/01/24
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/25
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/26
- Re: Policy: Versioning Macros In The Archive,
Tom Howard <=
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/26
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27