| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <HTML |
| ><HEAD |
| ><TITLE |
| >Upgrading to New Releases</TITLE |
| ><META |
| NAME="GENERATOR" |
| CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK |
| REL="HOME" |
| TITLE="The Bugzilla Guide - 2.20.1 |
| Release" |
| HREF="index.html"><LINK |
| REL="UP" |
| TITLE="Administering Bugzilla" |
| HREF="administration.html"><LINK |
| REL="PREVIOUS" |
| TITLE="Groups and Group Security" |
| HREF="groups.html"><LINK |
| REL="NEXT" |
| TITLE="Bugzilla Security" |
| HREF="security.html"></HEAD |
| ><BODY |
| CLASS="section" |
| BGCOLOR="#FFFFFF" |
| TEXT="#000000" |
| LINK="#0000FF" |
| VLINK="#840084" |
| ALINK="#0000FF" |
| ><DIV |
| CLASS="NAVHEADER" |
| ><TABLE |
| SUMMARY="Header navigation table" |
| WIDTH="100%" |
| BORDER="0" |
| CELLPADDING="0" |
| CELLSPACING="0" |
| ><TR |
| ><TH |
| COLSPAN="3" |
| ALIGN="center" |
| >The Bugzilla Guide - 2.20.1 |
| Release</TH |
| ></TR |
| ><TR |
| ><TD |
| WIDTH="10%" |
| ALIGN="left" |
| VALIGN="bottom" |
| ><A |
| HREF="groups.html" |
| ACCESSKEY="P" |
| >Prev</A |
| ></TD |
| ><TD |
| WIDTH="80%" |
| ALIGN="center" |
| VALIGN="bottom" |
| >Chapter 3. Administering Bugzilla</TD |
| ><TD |
| WIDTH="10%" |
| ALIGN="right" |
| VALIGN="bottom" |
| ><A |
| HREF="security.html" |
| ACCESSKEY="N" |
| >Next</A |
| ></TD |
| ></TR |
| ></TABLE |
| ><HR |
| ALIGN="LEFT" |
| WIDTH="100%"></DIV |
| ><DIV |
| CLASS="section" |
| ><H1 |
| CLASS="section" |
| ><A |
| NAME="upgrading" |
| >3.11. Upgrading to New Releases</A |
| ></H1 |
| ><P |
| > 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: |
| </P |
| ><P |
| ></P |
| ><UL |
| ><LI |
| ><P |
| > If the new version is a revision or a new point release |
| </P |
| ></LI |
| ><LI |
| ><P |
| > How many local changes (if any) have been made |
| </P |
| ></LI |
| ></UL |
| ><DIV |
| CLASS="section" |
| ><H2 |
| CLASS="section" |
| ><A |
| NAME="upgrading-version-defns" |
| >3.11.1. Version Definitions</A |
| ></H2 |
| ><P |
| > Bugzilla displays the version you are using at the top of most |
| pages you load. It will look something like '2.16.7' or '2.18rc3' |
| or '2.19.1+'. The first number in this series is the Major Version. |
| This does not change very often (that is to say, almost never); |
| Bugzilla was 1.x.x when it was first created, and went to 2.x.x |
| when it was re-written in perl in Sept 1998. If/When the major version |
| is changed to 3.x.x, it will signify a significant structural change |
| and will be accompanied by much fanfare and many instructions on |
| how to upgrade, including a revision to this page. :) |
| </P |
| ><P |
| > The second number in the version is called the 'minor number', and |
| a release that changes the minor number is called a 'point release'. |
| An even number in this position (2.14, 2.16, 2.18, 2.20, etc.) |
| represents a stable version, while an odd number (2.17, 2.19, etc.) |
| represents a development version. In the past, stable point releases |
| were feature-based, coming when certain enhancements had been |
| completed, or the Bugzilla development team felt that enough |
| progress had been made overall. As of version 2.18, however, |
| Bugzilla has moved to a time-based release schedule; current plans |
| are to create a stable point release every 6 months or so after |
| 2.18 is deployed. |
| </P |
| ><P |
| > The third number in the Bugzilla version represents a bugfix version. |
| Bugfix Revisions are normally released only to address security |
| vulnerabilities; in the future, it is likely that the Bugzilla |
| development team will back-port bugfixes in a new point release to |
| the old point release for a limited period. Once enough of these |
| bugfixes have accumulated (or a new security vulnerability is |
| identified and closed), a bugfix release will be made. As an |
| example, 2.16.6 was a bugfix release, and improved on 2.16.5. |
| </P |
| ><DIV |
| CLASS="note" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="note" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/note.gif" |
| HSPACE="5" |
| ALT="Note"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > When reading version numbers, everything separated by a point ('.') |
| should be read as a single number. It is <EM |
| >not</EM |
| > |
| the same as decimal. 2.14 is newer than 2.8 because minor version |
| 14 is greater than minor version 8. 2.24.11 would be newer than |
| 2.24.9 (because bugfix 11 is greater than bugfix 9. This is |
| confusing to some people who aren't used to dealing with software. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ></DIV |
| ><DIV |
| CLASS="section" |
| ><H2 |
| CLASS="section" |
| ><A |
| NAME="upgrading-methods" |
| >3.11.2. Upgrading - Methods and Procedure</A |
| ></H2 |
| ><P |
| > There are three different ways to upgrade your installation. |
| </P |
| ><P |
| ></P |
| ><OL |
| TYPE="1" |
| ><LI |
| ><P |
| > Using CVS (<A |
| HREF="upgrading.html#upgrade-cvs" |
| >Section 3.11.2.1</A |
| >) |
| </P |
| ></LI |
| ><LI |
| ><P |
| > Downloading a new tarball (<A |
| HREF="upgrading.html#upgrade-tarball" |
| >Section 3.11.2.2</A |
| >) |
| </P |
| ></LI |
| ><LI |
| ><P |
| > Applying the relevant patches (<A |
| HREF="upgrading.html#upgrade-patches" |
| >Section 3.11.2.3</A |
| >) |
| </P |
| ></LI |
| ></OL |
| ><P |
| > Each of these options has its own pros and cons; the one that's |
| right for you depends on how long it has been since you last |
| installed, the degree to which you have customized your installation, |
| and/or your network configuration. (Some discussion of the various |
| methods of updating compared with degree and methods of local |
| customization can be found in <A |
| HREF="cust-templates.html#template-method" |
| >Section 5.1.2</A |
| >.) |
| </P |
| ><P |
| > The larger the jump you are trying to make, the more difficult it |
| is going to be to upgrade if you have made local customizations. |
| Upgrading from 2.18 to 2.18.1 should be fairly painless even if |
| you are heavily customized, but going from 2.14 to 2.18 is going |
| to mean a fair bit of work re-writing your local changes to use |
| the new files, logic, templates, etc. If you have done no local |
| changes at all, however, then upgrading should be approximately |
| the same amount of work regardless of how long it has been since |
| your version was released. |
| </P |
| ><DIV |
| CLASS="warning" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="warning" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/warning.gif" |
| HSPACE="5" |
| ALT="Warning"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > 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. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ><P |
| > The examples in the following sections are written as though the |
| user were updating to version 2.18.1, but the procedures are the |
| same regardless of whether one is updating to a new point release |
| or simply trying to obtain a new bugfix release. Also, in the |
| examples the user's Bugzilla installation is found at |
| <TT |
| CLASS="filename" |
| >/var/www/html/bugzilla</TT |
| >. If that is not the |
| same as the location of your Bugzilla installation, simply |
| substitute the proper paths where appropriate. |
| </P |
| ><DIV |
| CLASS="section" |
| ><H3 |
| CLASS="section" |
| ><A |
| NAME="upgrade-cvs" |
| >3.11.2.1. Upgrading using CVS</A |
| ></H3 |
| ><P |
| > Every release of Bugzilla, whether it is a point release or a bugfix, |
| is tagged in CVS. Also, every tarball that has been distributed since |
| version 2.12 has been created in such a way that it can be used with |
| CVS once it is unpacked. Doing so, however, requires that you are able |
| to access cvs-mirror.mozilla.org on port 2401, which may not be an |
| option or a possibility for some users, especially those behind a |
| highly restrictive firewall. |
| </P |
| ><DIV |
| CLASS="tip" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="tip" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/tip.gif" |
| HSPACE="5" |
| ALT="Tip"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > If you can, updating using CVS is probably the most painless |
| method, especially if you have a lot of local changes. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ><P |
| > The following shows the sequence of commands needed to update a |
| Bugzilla installation via CVS, and a typical series of results. |
| </P |
| ><TABLE |
| BORDER="0" |
| BGCOLOR="#E0E0E0" |
| WIDTH="100%" |
| ><TR |
| ><TD |
| ><FONT |
| COLOR="#000000" |
| ><PRE |
| CLASS="programlisting" |
| > bash$ <B |
| CLASS="command" |
| >cd /var/www/html/bugzilla</B |
| > |
| bash$ <B |
| CLASS="command" |
| >cvs login</B |
| > |
| Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot |
| CVS password: <EM |
| >('anonymous', or just leave it blank)</EM |
| > |
| bash$ <B |
| CLASS="command" |
| >cvs -q update -r BUGZILLA-2_18_1 -dP</B |
| > |
| P checksetup.pl |
| P collectstats.pl |
| P globals.pl |
| P docs/rel_notes.txt |
| P template/en/default/list/quips.html.tmpl |
| <EM |
| >(etc.)</EM |
| > |
| </PRE |
| ></FONT |
| ></TD |
| ></TR |
| ></TABLE |
| ><DIV |
| CLASS="caution" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="caution" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/caution.gif" |
| HSPACE="5" |
| ALT="Caution"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > If a line in the output from <B |
| CLASS="command" |
| >cvs update</B |
| > begins |
| with a <SAMP |
| CLASS="computeroutput" |
| >C</SAMP |
| >, then 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. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ></DIV |
| ><DIV |
| CLASS="section" |
| ><H3 |
| CLASS="section" |
| ><A |
| NAME="upgrade-tarball" |
| >3.11.2.2. Upgrading using the tarball</A |
| ></H3 |
| ><P |
| > If you are unable (or unwilling) to use CVS, another option that's |
| always available is to obtain the latest tarball from the <A |
| HREF="http://www.bugzilla.org/download/" |
| TARGET="_top" |
| >Download Page</A |
| > and |
| create a new Bugzilla installation from that. |
| </P |
| ><P |
| > This sequence of commands shows how to get the tarball from the |
| command-line; it is also possible to download it from the site |
| directly in a web browser. If you go that route, save the file |
| to the <TT |
| CLASS="filename" |
| >/var/www/html</TT |
| > |
| directory (or its equivalent, if you use something else) and |
| omit the first three lines of the example. |
| </P |
| ><TABLE |
| BORDER="0" |
| BGCOLOR="#E0E0E0" |
| WIDTH="100%" |
| ><TR |
| ><TD |
| ><FONT |
| COLOR="#000000" |
| ><PRE |
| CLASS="programlisting" |
| > bash$ <B |
| CLASS="command" |
| >cd /var/www/html</B |
| > |
| bash$ <B |
| CLASS="command" |
| >wget ftp://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.1.tar.gz</B |
| > |
| <EM |
| >(Output omitted)</EM |
| > |
| bash$ <B |
| CLASS="command" |
| >tar xzvf bugzilla-2.18.1.tar.gz</B |
| > |
| bugzilla-2.18.1/ |
| bugzilla-2.18.1/.cvsignore |
| bugzilla-2.18.1/1x1.gif |
| <EM |
| >(Output truncated)</EM |
| > |
| bash$ <B |
| CLASS="command" |
| >cd bugzilla-2.18.1</B |
| > |
| bash$ <B |
| CLASS="command" |
| >cp ../bugzilla/localconfig* .</B |
| > |
| bash$ <B |
| CLASS="command" |
| >cp -r ../bugzilla/data .</B |
| > |
| bash$ <B |
| CLASS="command" |
| >cd ..</B |
| > |
| bash$ <B |
| CLASS="command" |
| >mv bugzilla bugzilla.old</B |
| > |
| bash$ <B |
| CLASS="command" |
| >mv bugzilla-2.18.1 bugzilla</B |
| > |
| </PRE |
| ></FONT |
| ></TD |
| ></TR |
| ></TABLE |
| ><DIV |
| CLASS="warning" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="warning" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/warning.gif" |
| HSPACE="5" |
| ALT="Warning"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > The <B |
| CLASS="command" |
| >cp</B |
| > commands both end with periods which |
| is a very important detail, it tells the shell that the destination |
| directory is the current working directory. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ><P |
| > This upgrade method will give you a clean install of Bugzilla with the |
| same version as the tarball. That's fine if you don't have any local |
| customizations that you want to maintain, but if you do then you will |
| need to reapply them by hand to the appropriate files. |
| </P |
| ><P |
| > It's worth noting that since 2.12, the Bugzilla tarballs come |
| CVS-ready, so if you decide at a later date that you'd rather use |
| CVS as an upgrade method, your code will already be set up for it. |
| </P |
| ></DIV |
| ><DIV |
| CLASS="section" |
| ><H3 |
| CLASS="section" |
| ><A |
| NAME="upgrade-patches" |
| >3.11.2.3. Upgrading using patches</A |
| ></H3 |
| ><P |
| > If you are doing a bugfix upgrade -- that is, one where only the |
| last number of the revision changes, such as from 2.16.6 to 2.16.7 |
| -- then you have the option of obtaining and applying a patch file |
| from the <A |
| HREF="http://www.bugzilla.org/download/" |
| TARGET="_top" |
| >Download Page</A |
| >. |
| This file is made available by the <A |
| HREF="http://www.bugzilla.org/developers/profiles.html" |
| TARGET="_top" |
| >Bugzilla |
| Development Team</A |
| >, and is a collection of all the bug fixes |
| and security patches that have been made since the last bugfix |
| release. If you are planning to upgrade via patches, it is safer |
| to grab this developer-made patch file than to read the patch |
| notes and apply all (or even just some of) the patches oneself, |
| as sometimes patches on bugs get changed before they get checked in. |
| </P |
| ><P |
| > As above, this example starts with obtaining the file via the |
| command line. If you have already downloaded it, you can omit the |
| first two commands. |
| </P |
| ><TABLE |
| BORDER="0" |
| BGCOLOR="#E0E0E0" |
| WIDTH="100%" |
| ><TR |
| ><TD |
| ><FONT |
| COLOR="#000000" |
| ><PRE |
| CLASS="programlisting" |
| > bash$ <B |
| CLASS="command" |
| >cd /var/www/html/bugzilla</B |
| > |
| bash$ <B |
| CLASS="command" |
| >wget ftp://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.0-to-2.18.1.diff.gz</B |
| > |
| <EM |
| >(Output omitted)</EM |
| > |
| bash$ <B |
| CLASS="command" |
| >gunzip bugzilla-2.18.0-to-2.18.1.diff.gz</B |
| > |
| bash$ <B |
| CLASS="command" |
| >patch -p1 < bugzilla-2.18.0-to-2.18.1.diff</B |
| > |
| patching file checksetup.pl |
| patching file collectstats.pl |
| patching file globals.pl |
| <EM |
| >(etc.)</EM |
| > |
| </PRE |
| ></FONT |
| ></TD |
| ></TR |
| ></TABLE |
| ><DIV |
| CLASS="warning" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="warning" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/warning.gif" |
| HSPACE="5" |
| ALT="Warning"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > Be aware that upgrading from a patch file does not change the |
| entries in your <TT |
| CLASS="filename" |
| >CVS</TT |
| > directory. |
| This could make it more difficult to upgrade using CVS |
| (<A |
| HREF="upgrading.html#upgrade-cvs" |
| >Section 3.11.2.1</A |
| >) in the future. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ></DIV |
| ></DIV |
| ><DIV |
| CLASS="section" |
| ><H2 |
| CLASS="section" |
| ><A |
| NAME="upgrading-completion" |
| >3.11.3. Completing Your Upgrade</A |
| ></H2 |
| ><P |
| > Regardless of which upgrade method you choose, you will need to |
| run <B |
| CLASS="command" |
| >./checksetup.pl</B |
| > before your Bugzilla |
| upgrade will be complete. |
| </P |
| ><TABLE |
| BORDER="0" |
| BGCOLOR="#E0E0E0" |
| WIDTH="100%" |
| ><TR |
| ><TD |
| ><FONT |
| COLOR="#000000" |
| ><PRE |
| CLASS="programlisting" |
| > bash$ <B |
| CLASS="command" |
| >cd bugzilla</B |
| > |
| bash$ <B |
| CLASS="command" |
| >./checksetup.pl</B |
| > |
| </PRE |
| ></FONT |
| ></TD |
| ></TR |
| ></TABLE |
| ><DIV |
| CLASS="warning" |
| ><P |
| ></P |
| ><TABLE |
| CLASS="warning" |
| WIDTH="100%" |
| BORDER="0" |
| ><TR |
| ><TD |
| WIDTH="25" |
| ALIGN="CENTER" |
| VALIGN="TOP" |
| ><IMG |
| SRC="../images/warning.gif" |
| HSPACE="5" |
| ALT="Warning"></TD |
| ><TD |
| ALIGN="LEFT" |
| VALIGN="TOP" |
| ><P |
| > The period at the beginning of the command |
| <B |
| CLASS="command" |
| >./checksetup.pl</B |
| > is important and can not |
| be omitted. |
| </P |
| ></TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ><P |
| > If you have done a lot of local modifications, it wouldn't hurt |
| to run the Bugzilla Testing suite. This is not a required step, |
| but it isn't going to hurt anything, and might help point out |
| some areas that could be improved. (More information on the |
| test suite can be had by following this link to the appropriate |
| section in the <A |
| HREF="http://www.bugzilla.org/docs/developer.html#testsuite" |
| TARGET="_top" |
| >Developers' |
| Guide</A |
| >.) |
| </P |
| ></DIV |
| ></DIV |
| ><DIV |
| CLASS="NAVFOOTER" |
| ><HR |
| ALIGN="LEFT" |
| WIDTH="100%"><TABLE |
| SUMMARY="Footer navigation table" |
| WIDTH="100%" |
| BORDER="0" |
| CELLPADDING="0" |
| CELLSPACING="0" |
| ><TR |
| ><TD |
| WIDTH="33%" |
| ALIGN="left" |
| VALIGN="top" |
| ><A |
| HREF="groups.html" |
| ACCESSKEY="P" |
| >Prev</A |
| ></TD |
| ><TD |
| WIDTH="34%" |
| ALIGN="center" |
| VALIGN="top" |
| ><A |
| HREF="index.html" |
| ACCESSKEY="H" |
| >Home</A |
| ></TD |
| ><TD |
| WIDTH="33%" |
| ALIGN="right" |
| VALIGN="top" |
| ><A |
| HREF="security.html" |
| ACCESSKEY="N" |
| >Next</A |
| ></TD |
| ></TR |
| ><TR |
| ><TD |
| WIDTH="33%" |
| ALIGN="left" |
| VALIGN="top" |
| >Groups and Group Security</TD |
| ><TD |
| WIDTH="34%" |
| ALIGN="center" |
| VALIGN="top" |
| ><A |
| HREF="administration.html" |
| ACCESSKEY="U" |
| >Up</A |
| ></TD |
| ><TD |
| WIDTH="33%" |
| ALIGN="right" |
| VALIGN="top" |
| >Bugzilla Security</TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ></BODY |
| ></HTML |
| > |
