Re: obsoleted vs acinclude tool

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>  > [CVS Id is fine]
>
> One more question: Would it make sense to _enforce_ that the macros
> are version-ed by _our_ CVS? 
>
> The advantage is that this would _guarantee_ an up-to-date version
> number for every macro. Furthermore, we could get rid of one more
> field in the submission format; one less for the authors to worry
> about.
>
> I believe that the author controlling the version number is
> impractical for the following reasons:
>
>  - We will have inconsistent version-ing schemes for macros.
>
>  - Authors may forget to bump the version when submitting patches.
>
>  - It is bound to create ambiguities when somebody but the author
>    submits a patch.
>
>  - It causes version numbers to "jump".

In a way, inconsistent version numbers are not our problem, it is
the problem of the author and how to handle bug request. I should
however be policy to add _some_ version number, not needfully be
a cvs id. It was good as is, in the ac-archive documentation to
have an example that uses @version and uses $Id: as the model.
So far, I guess that most will just accept this model unless they
have reason to do otherwise, so what, let them have it ;-)


> [...]
>  > when is a macro "name" free again?
>
> Gosh, I didn't think of that! Good point.
>
> What I don't understand though, is why we need _three_ stages for
> that? As far as I can tell, two should suffice, because when the macro
> is gone ("finalized"), it is gone. There is no entry left; the name is
> free. Am I missing something?

Nope. That's it. "Finalized" means it is not anymore part of the
ac-archive, neither its visual or hard-to-reach content pages.
An old version can only be extracted from old tarballs, and that
should be enough for every project administrator that has
forgotten to update the projects in time to clean them off any
occurences of "obsoleted" macros. Even the "deleted" stage is
only a convenience format - so that people who wonder why
something broke in the last update can still reach an easy
answer via web searches and set up local means to adapt to the
situation even without a need to update the project sources by
creating a local copy of the deleted macro. To guard a macro
name in the "deleted" stage, well, that could even be seen as
a "soft" requirement. It should be alteast one or two releases
in between without that name so that no project suddenly jumps
on a macro with the same name but completely different
behaviour. Well, actually I would even say that the "obsoleted"
stage time might be correlated to the time the macro had been
around before - a macro that was killed just a few weeks after
it came into existance should get faster through the cleanup
stages. Just my 2 cent...

have fun, guido