Re: Policy: Versioning Macros In The Archive

[Peter Simons]

Tom Howard wrote:

 >> Peter Simons wrote:
 >>
 >> 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.

Thanks for pointing that out. I almost hadn't noticed.


 > Well, I can see your sold on date stamps.

Yes:

  http://www.gnu.org/software/ac-archive/policy.html#use-of-the-version-tag


 > In that case, can we name them correctly?

Tom, please pay more attention to what you are saying when
talking to me. Asking "Can we name them correctly?" implies
that the name "@version" would be _incorrect_. That may be
your perception, but it obviously isn't mine. So starting
the suggestion by saying "your choice sucks, so here is a
better one" is a great way to start a flame war, but it is
very unlike to _achieve_ anything.

If you want me to change any aspect of my software or
policy, you will have to convince me. That requires stating
objective reasons for and benefits of your proposed change.
If you don't provide those, I won't do it. Just saying "what
you do is wrong, so let's do what I want" will not suffice.


 > 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

It is my firm believe that when the average user of the
archive sees two different copies of the same macro, and one
of them states

 @version 2000-04-01

while the other one states

 @version 2005-01-26

..., then he will know _exactly_ what these tags mean.


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

That sounds very nice indeed. I would love to have it. Do
you think you can set that up _working_ in a branch of the
repository? Once it does work, I'll happily look at it and
integrate it into the main CVS trunk together with you.


 > 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

I am not quite sure whether this approach fits the way our
users actually use the archive. My guess would be that very
few people make sweeping changes all over the repository,
most of them will probably modify only a single macro. Those
who do make sweeping changes have CVS commit rights to begin
with.

That doesn't mean having "make patch" wouldn't be useful,
though. The features we provide also shape the way the users
use the archive.


 > With a version number, at least I can indicate the
 > severity of the change form version to version.

What kind of severities does the GNU Autoconf Archive want
to indicate? Remember that we are distributing a bunch of m4
files, not an operating system. I cannot imagine any case
where someone would see

  autoconf-archive-2.0.tar.gz

on the web site, and would then download

  autoconf-archive-1.9.1.tar.gz

instead because he was afraid of the "major changes". So
what use does the more complex version number have?

People just want to know which release is the _latest_. And
dates do that better than anything else, because they
naturally represent _time_.


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

I doubt there is any "right" or "wrong" when it comes to
these kind of decisions, and I have great difficulties
dealing with people who talk in terms of "right" or "wrong"
about this kind of stuff. Donald Knuth has been signifying
the version of his TeX software by converging against Pi.
Nobody else has been doing that, so according to your logic,
Donald Knuth was WRONG.

So please go ahead and e-email him to let him know that he
is a prick and that TeX is fundamentally broken and offer
him your help in getting it fixed with some kick-ass
Automake script. I bet you wouldn't be doing that. When it
comes to my project though, you do exactly that.

Peter