httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Antwort: [STATUS] (httpd-docs-2.0) Wed Jan 15 23:45:43 EST 2003
Date Mon, 20 Jan 2003 11:57:21 GMT

> Decisions pending
> =================
> - /manual/x.y/
> +1: nd
> -0: Kess

I am +1 for the "/manual/x.y/" idea, as it makes the
"/manual/" directory a project tree containing all other
documentation variants, whereas "/docs-x.y" does not
(keeps several such directories as independent trees).
This one looks like the most generic approach to the
topic. (Using "/docs/x.y/" would be equivalent.)

> - Where to put docs checkout on website
> - Leave it at /docs-x.y/
> +1: Joshua, Erik, Kess
> 0: nd

On the other hand, the "/docs-x.y/" has the advantage of
easily allowing for one additional link to "the current"
version of the documentation, which currently is the 1.3

So my proposal would be:
1. use the "/manual/x.y/" model and
2. additionally have a "/manual/current/" link that would
   then take over the function of pointing to the version
   the Apache Group would consider to be "the current one",
   like it seems to have been the idea of the "/docs/" URLs.
This would then include having a
page as a root of all documentation, listing the set of all
available versions and explaining the meaning of "/current"
(i. e. why it currently points to which version).
This one might possibly be a CGI script reading the docu-
mentation root directory, so that it wouldn't need main-
tenance when new documentation releases are introduced.
As this script isn't a part of any shipped documentation
version it would not make the documentation dependend on
CGI when installed on a user system.

The difference between this new model and the one in use
now may be only marginal, so that staying with the old
mechanism might just be reasonable to keep the URLs stable.
(Would the "/manual/x.y/" concept include rewriting the old
URLs for compatibility's sake?)

> - /x.y/manual
> -1: Erik, nd
> 0: Kess

The third variant IMHO would make sense only if all Apache
subprojects would migrate to this mechanism, and it would
force them to bundle their version numbers.
Therefore I am -0 on the "/x.y/whatever" idea.

Regards, Michael

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message