5.8. upgrading to new releases

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.

1. using cvs (example 5-1)

2. downloading a new tarball (example 5-2)

3. applying the relevant patches (example 5-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 5-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 5-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 5-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 (for minor spelling fixes and the like). it is also theorectically 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 5-1) more difficult in the future.