summaryrefslogtreecommitdiffstats
path: root/docs/en/rst/installing/upgrading.rst
blob: f37998cf8f40b4343f0e4c1e9e489b9c7a554bec (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
.. _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.

.. 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 two steps:

1. Move to running from a Git checkout, while staying on exactly the same release.
2. 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.