You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Joshua Slive <jo...@slive.ca> on 2003/07/24 21:26:56 UTC
upgrading
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
+ example, 2.0.50 to 2.0.51), please skip down to the <a
+ href="#upgrading">upgrading</a> section.</p>
+
</summary>
<seealso><a href="invoking.html">Starting Apache</a></seealso>
@@ -297,7 +301,7 @@
<dd>Header file search directories ("<code>-I<em>dir</em></code>").</dd>
- <dt><code>TARGET=...</code> [Default: <code>apache</code>]</dt>
+ <dt><code>TARGET=...</code> [Default: <code>httpd</code>]</dt>
<dd>Name of the executable which will be built.</dd>
@@ -547,7 +551,7 @@
<section id="install"><title>Install</title>
- <p>Now its time to install the package under the configured
+ <p>Now it's time to install the package under the configured
installation <em>PREFIX</em> (see <code>--prefix</code> option
above) by running:</p>
@@ -588,6 +592,40 @@
running:</p>
<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
+ 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
+ upgrade from one version to the next, you need only copy the
+ <code>config.nice</code> file to the source tree of the new
+ version, edit it to make any desired changes, and then run:</p>
+
+ <example>
+ $ ./config.nice<br />
+ $ make<br />
+ $ make install<br />
+ $ <em>PREFIX</em>/bin/apachectl stop<br />
+ $ <em>PREFIX</em>/bin/apachectl start<br />
+ </example>
+
+ <p>Of course, you should always test any new version in your
+ environment before putting it into production.</p>
</section>
</manualpage>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: upgrading
Posted by Joshua Slive <jo...@slive.ca>.
On Thu, 24 Jul 2003, Mads Toftum wrote:
> On Thu, Jul 24, 2003 at 03:26:56PM -0400, Joshua Slive wrote:
> > Here's a patch to install.xml to deal with upgrading. Feedback welcome.
> >
> Maybe suggest that people read CHANGES first?
> Can we really be sure that all upgrades will be that smooth? I know that
> people try their best to make it so, but there could still be bigger
> changes even in 2.0.x and definetely in 2.1.x.
> Should it say something about 3rd party modules?
Referencing CHANGES is a good idea. As far as if this will work
consistently, we now have made a commitment to our users that this upgrade
process will work across minor versions. Major version changes are a
different story. I tried to include enough conditional language to
indicate that people still need to be careful, just in case something is
missed.
Third party modules don't need to be upgraded since the module API is
fixed across minor versions. I tried to cover this by saying "all your
modules will continue to work". Do I need to be more specific?
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: upgrading
Posted by Mads Toftum <ma...@toftum.dk>.
On Thu, Jul 24, 2003 at 03:26:56PM -0400, Joshua Slive wrote:
> Here's a patch to install.xml to deal with upgrading. Feedback welcome.
>
Maybe suggest that people read CHANGES first?
Can we really be sure that all upgrades will be that smooth? I know that
people try their best to make it so, but there could still be bigger
changes even in 2.0.x and definetely in 2.1.x.
Should it say something about 3rd party modules?
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: upgrading
Posted by Erik Abele <er...@codefaktor.de>.
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: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org