This is the 2.16 version of The Bugzilla Guide. It is so named
- to match the current version of Bugzilla. If you are
+>
This is the 2.17.3 version of The Bugzilla Guide. It is so named
+ to match the current version of Bugzilla.
+
+ This version of the guide, like its associated Bugzilla version is a
+ development version. Information is subject to change between now and
+ when 2.18 is released.
+
+ If you are
reading this from any source other than those below, please
check one of these mirrors to make sure you are reading an
up-to-date version of the Guide.
The latest version of this document can always be checked out via CVS.
diff --git a/docs/html/stepbystep.html b/docs/html/stepbystep.html
index 09dea6ccf..27870e9ae 100644
--- a/docs/html/stepbystep.html
+++ b/docs/html/stepbystep.html
@@ -81,7 +81,7 @@ CLASS="section"
>
MySQL database server
- (3.23.6 or greater)
+ (3.23.41 or greater)
GD::Chart
+>
GD::Graph
(any) for bug charting
4.1.5.1. DBI
4.1.5.2. Data::Dumper
4.1.5.3. MySQL-related modules
4.1.5.4. TimeDate modules
4.1.5.5. GD (optional)
4.1.5.6. Chart::Base (optional)
4.1.5.7. Template Toolkit
4.1.6. HTTP Server
4.1.7. Bugzilla
4.1.8. Setting Up the MySQL Database
4.1.9. 4.1.10. Securing MySQL
4.1.11. Configuring Bugzilla
4.5.1. Bundle::Bugzilla makes me upgrade to Perl 5.6.1
4.5.2. DBD::Sponge::db prepare failed
5.9. Upgrading to New Releases
A plain Bugzilla is fairly easy to upgrade from one version to a
- newer one. Always read the release notes to see if there are any issues
- that you might need to take note of. It is recommended that you take a
- backup of your database and your entire Bugzilla installation before attempting an
- upgrade. You can upgrade a 'clean' installation by untarring a new
- tarball over the old installation. If you are upgrading from 2.12 or
- later, and have cvs installed, you can type cvs -z3 update,
- and resolve conflicts if there are any.
+>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 5-1)
Downloading a new tarball (Example 5-2)
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.
However, things get a bit more complicated if you've made
- changes to Bugzilla's code. In this case, you may have to re-make or
- reapply those changes. One good method is to take a diff of your customized
- version against the original, so you can survey all that you've changed.
- Hopefully, templatization will reduce the need for
- this in the future.
From version 2.8 onward, Bugzilla databases can be automatically
- carried forward during an upgrade. However, because the developers of
- Bugzilla are constantly adding new
- tables, columns and fields, you'll probably get SQL errors if you just
- update the code and attempt to use Bugzilla. Always run the
+>These examples also assume that your Bugzilla installation is at
checksetup.pl
- script whenever you upgrade your installation.
If you are running Bugzilla version 2.8 or lower, and wish to
- upgrade to the latest version, please consult the file,
- "UPGRADING-pre-2.8" in the Bugzilla root directory after untarring the
- archive.
/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.
+ |
+