Re: obsoleted vs acinclude tool

[Guido Draheim]

Peter Simons schrieb:
> 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?

Just as is - most are fine with using
   @version $Id: ... $
which makes the automatic cvs version the one to differentiate.
In fact, in most cases the maintainance process does only need
_some_ kind of number that is ever increasing, no matter if that
is manual or automatic. Most will see automatic as better, and
that is why most macros will stay and use a cvs tag - IMO. ;-)

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

agreed. :-)

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

Nope. If you have some automatic process in the range, well,
let's use it. I was not aware of that automatism, ye know...

>  > "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?

Quite so. The reason: when is a macro "name" free again?
Most probably, the ac-archive software will handle/index
the macros by their word stem, no two macros shall exist
under the same name. There must be some point when an
obsoleted macro is neither packaged nor searchable in
the ac-archive (and what about giving ambiguities in a
google search?). That makes it so it needs to be
"finalized" at some point - which cleans its visual
existance in this world. It is okay to keep somewhere
a record and a backup but otherwise it is lost to the
world. (hint: I did later remember the term "finalize"
used in multi-level deletion algorithms - to return
the resources for reallocation, and let the object be
null in live data stock (existance on backup is not
considered)).

obsoleted - deleted - finalized.