diff options
Diffstat (limited to 'docs/en/rst/installing/upgrading.rst')
| -rw-r--r-- | docs/en/rst/installing/upgrading.rst | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/docs/en/rst/installing/upgrading.rst b/docs/en/rst/installing/upgrading.rst new file mode 100644 index 000000000..f43897fb3 --- /dev/null +++ b/docs/en/rst/installing/upgrading.rst @@ -0,0 +1,70 @@ +.. _upgrading: + +Upgrading +######### + +You can upgrade Bugzilla from any version to any later version in one go - +there is no need to pass through intermediate versions unless you are changing +the method by which you obtain the code along the way. + +.. warning:: Upgrading is a one-way process. You cannot "downgrade" an + upgraded Bugzilla. If you wish to revert to the old Bugzilla + version for any reason, you will have to restore your system + from a backup. Those with critical data or large installations may wish + to test the upgrade on a development server first, using a copy of the + production data and configuration. + +Bugzilla uses the Git version control system to store its code. A modern +Bugzilla installation consists of a checkout of a stable version of the code +from our Git repository. This makes upgrading much easier. If this is +already true of your installation, see :ref:`upgrading-with-git`. + +Before Git, we used to use Bazaar and, before that, CVS. If your installation +of Bugzilla consists of a checkout from one of those two systems, you need to +upgrade in three steps: + +1. Upgrade to the latest point release of your current Bugzilla version. +2. Move to Git while staying on exactly the same release. +3. Upgrade to the latest Bugzilla using the instructions for :ref:`upgrading-with-git`. + +See :ref:`migrating-from-bazaar` or :ref:`migrating-from-cvs` as appropriate. + +Some Bugzillas were installed simply by downloading a copy of the code as +an archive file ("tarball"). However, recent tarballs have included source +code management system information, so you may be able to use the Git, Bzr +or CVS instructions. + +If you aren't sure which of these categories you fall into, to find out which +version control system your copy of Bugzilla recognizes, look for the +following subdirectories in your root Bugzilla directory: + +* :file:`.git`: you installed using Git - follow :ref:`upgrading-with-git`. +* :file:`.bzr`: you installed using Bazaar - follow :ref:`migrating-from-bazaar`. +* :file:`CVS`: you installed using CVS - follow :ref:`migrating-from-cvs`. +* None of the above: you installed using an old tarball - follow + :ref:`migrating-from-a-tarball`. + +It is also possible, particularly if your server machine does not have and +cannot be configured to have access to the public internet, to upgrade using +a tarball. See :ref:`upgrading-with-a-tarball`. + +Whichever path you use, you may need help with +:ref:`upgrading-customizations`. + +.. toctree:: + :maxdepth: 1 + + upgrading-with-git + migrating-from-bzr + migrating-from-cvs + migrating-from-a-tarball + upgrading-with-a-tarball + upgrading-customizations + +Bugzilla can automatically notify administrators when new releases are +available if the :param:`upgrade_notification` parameter is set. +Administrators will see these notifications when they access the Bugzilla home +page. Bugzilla will check once per day for new releases. If you are behind a +proxy, you may have to set the :param:`proxy_url` parameter accordingly. If +the proxy requires authentication, use the +:paramval:`http://user:pass@proxy_url/` syntax. |