httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: docs on APACHE_2_0_BRANCH
Date Wed, 04 Dec 2002 14:28:41 GMT
At 07:32 AM 12/4/2002, André Malo wrote:
>* Joshua Slive wrote:
>> I have moved the docs-2.0 checkout on to the
>> APACHE_2_0_BRANCH tag so that it will contain the correct docs to go along
>> with 2.0.  I moved what used to be called docs-2.0 to docs-2.1, but I
>> haven't yet linked it from anywhere.
>For the 2.0 ist probably too late, but should we consider to create a 
>directory structure like
>? (<version> == major version aka 2.1, 2.2 etc)

I'm presuming you are talking about the website?  Since binaries don't
peacefully coexist by default (in apache/bin we have httpd, so 
in apache/manual we have that httpd's docs) and version control should
make things simpler in the long run [short term growing pains, and
changes in strategy aside.]

Why not create the desired URI structure now, and redirect /docs/, /docs-2.0/,
etc.  However, as are 1.3 today... Perhaps we choose
a new nick for the docs (simply /manual/2.0/ etc?) and/or keep the revision
as the top-level identifier (e.g.

>> As far as documentation development on this new system, any changes that
>> are not specific to new features in 2.1 should be made both to HEAD and to
>> the branch.  If the change is substantial, it might be a good idea to
>> commit to head first, then wait a few days for feedback before committing
>> to the branch.  But I don't think we need any strict rules.
>At this point a question. Since 2.1 is stated as "development version" what 
>are the docs in HEAD now actually for? 2.1 or 2.2?
>We also need to change all occuring version numbers "2.0" (in headings, 
>breadcrumb etc.) to appropriate values (2.1 or 2.2 ;-)

I'm really thinking that (using merges) it's actually easier to maintain docs
on APACHE_2_0_BRANCH and merge them to head occasionally.  Since
"new" features are documented on cvs HEAD, all of the other changes will
merge 'underneath' the latest 'n greatest new stuff.

We could set up some schema where the changes get merged once/week 
(obviously a maintainer is needed, and sometimes conflicts must be resolved.)  
But it is much safer to assume "all these 2.0 changes are also 2.1 changes"
then visa-versa.


View raw message