From: Joshua Slive Date: Mon, 28 Jul 2003 14:16:00 +0000 (+0000) Subject: Add some documentation on upgrading from one minor version to the next. X-Git-Tag: pre_ajp_proxy~1345 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=e28f99c37421aa5f4721a1b82ef44c6e2b3a4a46;p=apache Add some documentation on upgrading from one minor version to the next. Reviewed by: Mads Toftum, Erik Abele, Michael Schroepl git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@100811 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/install.html.en b/docs/manual/install.html.en index 6523308544..929cbbe6e2 100644 --- a/docs/manual/install.html.en +++ b/docs/manual/install.html.en @@ -37,6 +37,9 @@ to create an environment that looks like many other Open Source projects.

+

If you are upgrading from one minor version to the next (for + example, 2.0.50 to 2.0.51), please skip down to the upgrading section.

+

See also

top
@@ -315,7 +319,7 @@
Header file search directories ("-Idir").
-
TARGET=... [Default: apache]
+
TARGET=... [Default: httpd]
Name of the executable which will be built.
@@ -561,7 +565,7 @@ separated by a colon.

Install

-

Now its time to install the package under the configured +

Now it's time to install the package under the configured installation PREFIX (see --prefix option above) by running:

@@ -598,6 +602,54 @@ separated by a colon. running:

$ PREFIX/bin/apachectl stop

+
top
+
+

Upgrading

+ +

The first step in upgrading is to read the release announcement + and the file CHANGES in the source distribution to + find any changes that may affect your site. When changing between + major releases (for example, from 1.3 to 2.0 or from 2.0 to 2.2), + there will likely be major differences in the compile-time and + run-time configuration that will require manual adjustments. All + modules will also need to be upgraded to accomodate changes in the + module API.

+ +

Upgrading from one minor version to the next (for example, from + 2.0.55 to 2.0.57) is easier. The make install + process will not overwrite any of your existing documents, log + files, or configuration files. In addition, the developers make + every effort to avoid incompatible changes in the + configure options, run-time configuration, or the + module API between minor versions. In most cases you should be able to + use an identical configure 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.)

+ +

If you kept the source tree from your last installation, + upgrading is even easier. The file config.nice in + the root of the old source tree contains the exact + configure command line that you used to configure the + source tree. Then to upgrade from one version to the next, you + need only copy the config.nice file to the source + tree of the new version, edit it to make any desired changes, and + then run:

+ +

+ $ ./config.nice
+ $ make
+ $ make install
+ $ PREFIX/bin/apachectl stop
+ $ PREFIX/bin/apachectl start
+

+ +
You should always test any new version in your + environment before putting it into production. For example, you + can install and run the new version along side the old one by + using a different --prefix and a + different port (by adjusting the Listen directive) to test for any + incompatibilities before doing the final upgrade.

Available Languages:  de  | diff --git a/docs/manual/install.xml b/docs/manual/install.xml index e85463acfe..bd7fd4cc19 100644 --- a/docs/manual/install.xml +++ b/docs/manual/install.xml @@ -21,6 +21,10 @@ to create an environment that looks like many other Open Source projects.

+

If you are upgrading from one minor version to the next (for + example, 2.0.50 to 2.0.51), please skip down to the upgrading section.

+ Starting Apache @@ -297,7 +301,7 @@
Header file search directories ("-Idir").
-
TARGET=... [Default: apache]
+
TARGET=... [Default: httpd]
Name of the executable which will be built.
@@ -547,7 +551,7 @@ separated by a colon.
Install -

Now its time to install the package under the configured +

Now it's time to install the package under the configured installation PREFIX (see --prefix option above) by running:

@@ -589,5 +593,52 @@ separated by a colon. $ PREFIX/bin/apachectl stop
- +
Upgrading + +

The first step in upgrading is to read the release announcement + and the file CHANGES in the source distribution to + find any changes that may affect your site. When changing between + major releases (for example, from 1.3 to 2.0 or from 2.0 to 2.2), + there will likely be major differences in the compile-time and + run-time configuration that will require manual adjustments. All + modules will also need to be upgraded to accomodate changes in the + module API.

+ +

Upgrading from one minor version to the next (for example, from + 2.0.55 to 2.0.57) is easier. The make install + process will not overwrite any of your existing documents, log + files, or configuration files. In addition, the developers make + every effort to avoid incompatible changes in the + configure options, run-time configuration, or the + module API between minor versions. In most cases you should be able to + use an identical configure 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.)

+ +

If you kept the source tree from your last installation, + upgrading is even easier. The file config.nice in + the root of the old source tree contains the exact + configure command line that you used to configure the + source tree. Then to upgrade from one version to the next, you + need only copy the config.nice file to the source + tree of the new version, edit it to make any desired changes, and + then run:

+ + + $ ./config.nice
+ $ make
+ $ make install
+ $ PREFIX/bin/apachectl stop
+ $ PREFIX/bin/apachectl start
+ + + You should always test any new version in your + environment before putting it into production. For example, you + can install and run the new version along side the old one by + using a different --prefix and a + different port (by adjusting the Listen directive) to test for any + incompatibilities before doing the final upgrade. +