Re: obsoleted vs acinclude tool

[Peter Simons]

Guido Draheim writes:

 >> do we any longer _need_ the macro to have a "version" string?

 > Yes! 

Alright. :-) I see your point.

Another question: What exactly _is_ the macro's version? Is it the one
that comes from our CVS repository, or should the submitter be allowed
to set any version as he sees fit -- for instance if he's maintaining
the macro in his own CVS repository as well?


 > [Breaking backwards compatibility in an update.]

To summarize your points: We consider a macro "breaking backwards
compatibly" when its interface to the user changes or when the nature
of the test it performs changes. We do not consider it breaking
backwards compatibility if the macro is enhanced in a way that may
_may_ break things when used uncorrectly.

This is a subtle issue. I don't think that we can set rules in stone
that describe this correctly for all possible cases. But I think our
understanding so far is pretty good and should suffice.


 > To summarize: a change in a macro SHALL try to not break backward
 > compatibility unless there is a verrry good reason to do so.

I like that one. ;-)


 > I do not know whether there is actually a need to add an expiry
 > date [...]

The reason why I would like to have an expiry date is because then
macros can be moved from "obsolete" to "history" automatically by the
infrastructure, rather than the maintainer having to do it. To produce
a figure out of thin air: Let's keep the macro in "obsolete" for
exactly one year, then it goes away -- and into the history section.

Do you think that is inappropriate?


 > "deleted" (when it is only in google'able places) 
 > "removed" (when it is finally wiped off the archive)

Uh, when the macro is wiped off the archive, there isn't any state
anymore whatsoever. :-) Or did I misunderstand that?

Peter