Re: Policy: Versioning Macros In The Archive

[Guido Draheim]

Peter Simons wrote:
> Guido Draheim writes:
> 
>  >> These are all fields that my software uses internally
>  >> and which need to be consistent in order for the whole
>  >> thing to work. [...] Since, according to you, I can't
>  >> treat any fields as "internal" as long as I distribute
>  >> them publicly, I will stop distributing them.
> 
>  > Good lord, Peter, would you please stop overreacting, the
>  > message to you was "stop modifying what the submitter has
>  > given to you including the @version tag".
> 
> But Guido, that is exactly what this will accomplish! The
> solution is beautiful. I had the right idea from the start,
> I just didn't realize it! Instead of having the _internal_
> archive information in the m4 source code and stripping that
> for release, I'll have that information in a separate
> database which will be invisible to users of the archive.
> 
> This way, I can re-categorize, change, and re-organize
> everything just as I see fit, without ever having to modify
> the file that the submitter sent me!

That is almost but not entirely correct - I have started to
use those *.log files that will register meta-information
for the macros but I see them more as a fallback - if the
submitter wants a certain version tag then it should be
shown atleast additionally. Please keep that in mind when
cutting things.

> 
> So in short, the only tags the submitter knows are:
> 
>  @synopsis
>  @summary
> 
> This makes the whole thing a lot easier for everybody. And
> the best part is: I can store that internal database with
> the meta-information in XML, like I wanted to all the time.
> 
> Okay, I am sorry about the mess. I made a mistake when I
> decided to put the entire archive meta-data into CVS. I
> shouldn't have mixed up my stuff with the stuff the users
> submit. I apologize.
> 

Well, in the majority of cases the submitter will actually
request an obsoletion or additional author mark. Even more
so there should be a pointer to obsoletion and authorship
in any copy of the macro being around in different projects
(either acinclude.m4 or project-local m4/ subdirectory). In
the last message it did all sound as if you will be stripping
it out of the "redistributed macro" moving it to an internal
database - be very sure submitters will be calling you names
if you try that.

-- good luck, guido