Re: Policy: Versioning Macros In The Archive

[Peter Simons]

Tom Howard writes:

 > Well, if I rewrite my macros (for whatever reason), I
 > would like to be able to indicate that via the version
 > number (e.g. bump it from 1.x to 2.0), to indicate a
 > major change. If they could then be release as a
 > development snapshot or release candidate, then even
 > better.

You can: Put the information into the documentation or into
the m4 source code.

@version is an internal field of the archive; it represents
the version of your macro _in the archive_, not the version
you assigned the macro. I have explained my rationale for
this decision in great detail already, my major point being
that other people may modify your macro too; therefore the
archive cannot rely on your version information to be
authoritative. Since the archive cannot denote minor or
major releases for your macro, it doesn't, but just states
the day of the last modification.


 >> People just want to know which release is the _latest_.

 > Personally I want the latest stable release, not just the
 > latest release.

There are no stable or unstable releases of the archive.
_All_ our releases are stable. There is no reason to use a
release other than the latest one.


 >> Nobody else has been doing that, so according to your
 >> logic, Donald Knuth was WRONG.

 > Yes, I think he is, and you can quote me on that.

Okay.


 > One other thing about the version changes, do you realise
 > that you have effectively forked every single macro
 > except those maintained by yourself.

What does "fork" mean in that context?


 > What happens when I update my macro, do I have to keep my
 > copy in sync with your versioning system, or will you
 > take the burden of merging the versions?

Yes, I will take the burden of updating the contents of
@version on myself.

_Unless_, when you are committing into CVS directly. In that
case, it is your responsibility to bump the @version. That
is explained in:

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


 > If the latter, then why do you bother creating extra work
 > for yourself?

Because I want to have proper version information for the
contents of the archive.


 > If the former, what if the organisation I work for has a
 > macro versioning policy that conflicts with yours?

Either you submit your macro under a free license -- then
your policy is _not_ incompatible with ours --, or you do
not -- then we won't accept it.

Peter