> > One thought -- and perhaps this already exists -- is to introduce
> > @infoversion as the first tag that should appear in the input. This
> > specifies the major version of info to which the document was written,
and
> > would allow us to restructure info input a bit without breaking
backwards
> > compatibility.
>
> I don't see how this will solve back-compatibility problems, since
> @infoversion itself is not back-compatible.
Here's why:
The @infoversion attribute specifies the version of the makeinfo input
specification that the document conforms to. If the document requires info
version 5, and makeinfo version 3.12 barfs because it doesn't understand the
@infoversion tag, that's a good thing -- it has the right result, which is
that makeinfo 3.12 does not try to process a document it won't understand
anyway.
On the other hand, the presence of a version number allows *later* versions
of makeinfo to behave in backwards-compatible fashion.
> OTOH, if someone wants back-compatibility, they should refrain from using
> new features.
I agree, but this assumes that the input format itself is backward
compatible. Having a version number in the input relaxes that requirement in
some useful ways.
shap
