How to upgrade to BugZilla 3.0
BugZilla 3.0 stable was recently released, and upgrading an existing BugZilla installation is easy. Yesterday, I spent some time upgrading our 2.22.1 installation to the new 3.0 and have, so far, been impressed with the updates. Here’s a quick overview of the upgrade process (it might seem a bit unintuitive at first).
First, backup your current database and local BugZilla installation (so you can quickly roll back to a working version should something go wrong). I used mysqldump to get a copy of the “bugs” database: “mysqldump -u root -p bugs > bugs.sql”.
Second, grab a copy of the new BugZilla. As I’m installing on a Ubuntu box, I used the tarball, but there are different versions available for other operating systems (including, apparently, an unsupported automated installer, which I haven’t tried). Once you’ve downloaded it, move it to your web directory, unpack it, and name it something like bugzilla-3.0.
Third, copy the important stuff out of the old BugZilla (from the Upgrading to New Releases documentation):
bash$ cd bugzilla-3.0
bash$ cp -p ../bugzilla/localconfig* .
bash$ cp -pr ../bugzilla/data .
Note the “bugzilla” directory is your old BugZilla installation, while the bugzilla-3.0 is the new installation you just downloaded.
Fourth, run the “checksetup.pl” script in the bugzilla-3.0 directory. This script will go through your environment and alert you to any missing Perl modules, and update your database schema to the new version for BugZilla 3.0. I had to install several new Perl modules in order for the new version to work, which can be done using the command “perl -MCPAN -e ‘install [some::module]‘”, or you can just download the packages individually from CPAN and build/install them by hand.
One additional note about the checksetup.pl script: the new version of BugZilla is using a new data encoding for the database, which requires updating any existing data currently in your database to the new version (UTF-8, I believe). To do this, I needed to run the command “./contrib/recode.pl –guess”, which figured out my existing encoding and updated it to the new UTF-8 format. Check out the options for recode.pl (and consider trying the –dry-run flag first).
After running recode.pl, I needed to rerun my checksetup.pl to finish updating the database to the new version. Once done, my BugZilla installation was nearly complete. When going to the new BugZilla installation via my web browser, I noticed no images were appearing. It turned out to be a permissions problem. Make sure the owner/group and access rights are set properly for your BugZilla installation based on how you’re running Apache.
And that’s it! All my existing bug data appeared in the new version of BugZilla and I was ready to go.















Comments(2)
Just for accuracy, you probably want to use the -p option to the cp command when copying localconfig and the data directory. I don’t think we do anything that depends on the modification dates of the files in Bugzilla currently, but just for your own sanity it’s probably good to preserve the permissions and modification dates.
Thanks Dave – updated to include the -p option.