On Wed, 4 Dec 2002, William A. Rowe, Jr. wrote: > At 07:32 AM 12/4/2002, Andr� Malo wrote: > >For the 2.0 ist probably too late, but should we consider to create a > >directory structure like > > > >/docs/<version> > > > >? (<version> == major version aka 2.1, 2.2 etc) > Why not create the desired URI structure now, and redirect /docs/, /docs-2.0/, > etc. However, as httpd.apache.org/docs/ 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. httpd.apache.org/2.0/manual/)?
I think that if I was starting again today, this is certainly what I would do. But I'm not sure I see the point in switching now. There are MANY inbound links to the various manual pages, and while the redirect would keep from them breaking, it will still cause extra round-trips as well as problems with search engines, etc. I personally prefer to keep the URL stable. (But I would not object if a concesus developed to the contrary.) > >> 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 ;-) The thing in HEAD is 2.1. It will likely never be released to the public under that designation. (When it is ready, it will be called 2.2.) But the docs should still say 2.1 while it is in progress. Yes, all the headings need to be changed. Luckily, that is easy with our new system :-) > 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. I really don't have enough cvs expertise to know what is best here. Certainly there will be some pain any way we do it. But perhaps there is a benefit to concentrating that pain, so that we don't discourage casual documenters by making the process too complicated. My main concern is that when conflicts come up, they won't be one-time things. As soon as there is a conflict, it will repeat with every merge, right? Or is there some magic way to do this so that you only have to deal with the conflict once? Joshua.
