* the current page, but with an entry/link like "For older manuals,
      please see this index."

Agreed this is preferable. Not a fan of the gcc index page.

    changes to the manual the rename or reorder chapters, we're breaking
    those historical links.

Reordering isn't a problem; that doesn't break links. Renaming nodes is
what breaks links. And the answer is, 1) don't do it, and 2) if you feel
you simply must, leave an @anchor behind, and then existing links will
not be broken.  Anyway, the manual hardly changes nowadays, so it's not
an issue in practice.

To me, the redirection to a versioned url a la autoconf often leads to
the wrong behavior in the other direction: typically people want to link
or refer to the current version of node Foobar (whatever version it
might be), but it's too much trouble to do when you end up getting
redirected. So it doesn't happen, and then X years now people still
think autoconf-2.68, for example, is current because that's what the
link say. (Rather like bugs.gnu.org/NNNN being preferred, but since that
redirects, hardly anyone uses it and it's just manual labor to do
so. But I digress.)


    any other manual/<file> access would redirect to the latest version.
    that way we don't break links already out in the wild.

Agreed we certainly must not break existing links. But I'd rather have a
copy as the unversioned/canonical page than forced redirection in all
cases.  Both canonical and versioned urls are useful.

            https://www.gnu.org/software/automake/manual/1.15/
            https://www.gnu.org/software/automake/manual/1.16/
    (or if you prefer, 1.15.x and such)

If not publishing all versions, it would seem better to me to publish
the latest version of the manual for any given 1.x, not the first
version. I.e., 1.13.4, 1.14.1, 1.15.1, 1.16.5. I don't see that there's
anything especially magical about the "non-dot" releases like 1.15,
although I have no objection to publishing those too. --thanks, karl.



Reply via email to