3.9. Upgrading to New Releases
Upgrading is a one-way process. You should backup your database - and current Bugzilla directory before attempting the upgrade. If you wish - to revert to the old Bugzilla version for any reason, you will have to - restore from these backups. - |
Upgrading Bugzilla is something we all want to do from time to time, - be it to get new features or pick up the latest security fix. How easy - it is to update depends on a few factors. -
If the new version is a revision or a new point release
How many, if any, local changes have been made
There are also three different methods to upgrade your installation. -
Using CVS (Example 3-1)
Downloading a new tarball (Example 3-2)
Applying the relevant patches (Example 3-3)
Which options are available to you may depend on how large a jump - you are making and/or your network configuration. -
Revisions are normally released to fix security vulnerabilities - and are distinguished by an increase in the third number. For example, - when 2.16.2 was released, it was a revision to 2.16.1. -
Point releases are normally released when the Bugzilla team feels - that there has been a significant amount of progress made between the - last point release and the current time. These are often proceeded by a - stabilization period and release candidates, however the use of - development versions or release candidates is beyond the scope of this - document. Point releases can be distinguished by an increase in the - second number, or minor version. For example, 2.16.2 is a newer point - release than 2.14.5. -
The examples in this section are written as if you were updating - to version 2.16.2. The procedures are the same regardless if you are - updating to a new point release or a new revision. However, the chance - of running into trouble increases when upgrading to a new point release, - escpecially if you've made local changes. -
These examples also assume that your Bugzilla installation is at - /var/www/html/bugzilla. If that is not the case, - simply substitute the proper paths where appropriate. -
Example 3-1. Upgrading using CVS
Every release of Bugzilla, whether it is a revision or a point - release, is tagged in CVS. Also, every tarball we have distributed - since version 2.12 has been primed for using CVS. This does, however, - require that you are able to access cvs-mirror.mozilla.org on port - 2401. - -
If you can do this, updating using CVS is probably the most - painless method, especially if you have a lot of local changes. - |
bash$ cd /var/www/html/bugzilla -bash$ cvs login -Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot -CVS password: anonymous -bash$ cvs -q update -r BUGZILLA-2_16_2 -dP -P checksetup.pl -P collectstats.pl -P globals.pl -P docs/rel_notes.txt -P template/en/default/list/quips.html.tmpl - |
If a line in the output from cvs update - begins with a C that represents a - file with local changes that CVS was unable to properly merge. You - need to resolve these conflicts manually before Bugzilla (or at - least the portion using that file) will be usable. - |
You also need to run ./checksetup.pl - before your Bugzilla upgrade will be complete. - |
Example 3-2. Upgrading using the tarball
If you are unable or unwilling to use CVS, another option that's - always available is to download the latest tarball. This is the most - difficult option to use, especially if you have local changes. -
bash$ cd /var/www/html -bash$ wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.2.tar.gz -Output omitted -bash$ tar xzvf bugzilla-2.16.2.tar.gz -bugzilla-2.16.2/ -bugzilla-2.16.2/.cvsignore -bugzilla-2.16.2/1x1.gif -Output truncated -bash$ cd bugzilla-2.16.2 -bash$ cp ../bugzilla/localconfig* . -bash$ cp -r ../bugzilla/data . -bash$ cd .. -bash$ mv bugzilla bugzilla.old -bash$ mv bugzilla-2.16.2 bugzilla -bash$ cd bugzilla -bash$ ./checksetup.pl -Output omitted - |
The cp commands both end with periods which - is a very important detail, it tells the shell that the destination - directory is the current working directory. Also, the period at the - beginning of the ./checksetup.pl is important and - can not be omitted. - |
You will now have to reapply any changes you have made to your - local installation manually. - |
Example 3-3. Upgrading using patches
The Bugzilla team will normally make a patch file available for - revisions to go from the most recent revision to the new one. You could - also read the release notes and grab the patches attached to the - mentioned bug, but it is safer to use the released patch file as - sometimes patches get changed before they get checked in. - It is also theoretically possible to - scour the fixed bug list and pick and choose which patches to apply - from a point release, but this is not recommended either as what you'll - end up with is a hodge podge Bugzilla that isn't really any version. - This would also make it more difficult to upgrade in the future. -
bash$ cd /var/www/html/bugzilla -bash$ wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.1-to-2.16.2.diff.gz -Output omitted -bash$ gunzip bugzilla-2.16.1-to-2.16.2.diff.gz -bash$ patch -p1 < bugzilla-2.16.1-to-2.16.2.diff -patching file checksetup.pl -patching file collectstats.pl -patching file globals.pl - |
If you do this, beware that this doesn't change the entires in - your CVS directory so it may make - updates using CVS (Example 3-1) more difficult in the - future. - |