comments inline...
On 24/07/2003, at 09:26, Joshua Slive wrote:
Here's a patch to install.xml to deal with upgrading. Feedback welcome.
Index: install.xml =================================================================== RCS file: /home/cvs/httpd-2.0/docs/manual/install.xml,v retrieving revision 1.20 diff -u -r1.20 install.xml --- install.xml 27 Jun 2003 18:53:03 -0000 1.20 +++ install.xml 24 Jul 2003 19:26:45 -0000 @@ -21,6 +21,10 @@ to create an environment that looks like many other Open Source projects.</p>
+ <p>If you upgrading from one minor version to the next (for
Typo: 'If you *are* upgrading...'
<snip />
<example>$ <em>PREFIX</em>/bin/apachectl stop</example> +</section> + +<section id="upgrading"><title>Upgrading</title> + + <p>Upgrading from one minor version to the next is easy. The + <code>make install</code> process will not overwrite any of your + existing documents or your configuration file. In addition, the
Perhaps also mention the log files here? 'existing documents, configuration or log files. In addition, the'
+ developers make every effort to avoid incompatible changes in the
+ <code>configure</code> options, run-time configuration, or the
+ module API between minor versions. So for example, in a change
+ from 2.0.58 to 2.0.59, you should be able to use an identical
+ <code>configure</code> command line, an identical configuration
+ file, and all of your modules should continue to work. (This is
+ only valid for versions after 2.0.41; earlier versions have
+ incompatible changes.)</p>
+
+ <p>If you kept your source tree from your last installation,
+ upgrading is even easier. The file <code>config.nice</code>
+ in the root of the source tree contains the exact <code>configure</code>
+ command line used to configure the source tree. Then to
'command line used to configure the source tree *the last time*. Then to'
not quite sure, but perhaps we should be pedantically clear here :)
<snip />
+ <p>Of course, you should always test any new version in your + environment before putting it into production.</p> </section>
Can we put some more weight on this last paragraph? I think of a <strong> or even a <note type="warning">...just to be sure that everybody is aware that there is *always* a possibility to break things and that an upgrade isn't always as trouble-free as one might assume.
just my 0.02 €, hth...
Cheers, Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
