This past week I was faced with upgrading a really old installation of Bugzilla, version 2.18rc3 and move it forward to the current stable, 3.0.2 - what was of course critical, that the existing database of bugs be moved to the new version, so that bug numbers wouldn't change etc. I first tried to upgrade in-place the existing installation via CVS; this didn't work so happy as apparently moving from 2.18 to 3.0.2 isn't very easy due to numerous changes. So I decided to setup a new installation (even on a new server, so I could have my way with the environment and not worry about affecting the old one) - after getting all the pre-requisites of 3.0.2 taken care of and checksetup.pl finally ran and didn't complain about anything I was faced with moving the existing bugs from the old installation (and server) to the new one. In the documentation I had read about move.pl and importxml.pl and possibly something in contrib that would help in moving the bugs from one installation to another. I tried getting the move button working in the old version so I could some how do a search, tag everything and then have it send all the bugs via xml stuffed emails over to the new installation - this was simply not required. I decided to dump the old mysql database using mysqldump - then copy this file over to the new server, I scratched the database so it was fresh and simply read in the backup sql file I had made on the old server - when I properly set the dbpass in localconfig on the new version, and ran checksetup.pl - I was surprisingly given options to upgrade and convert the database to a new format (with a scary warning about UTF-8) - I forged ahead and said sure, go ahead, convert - it sat for a few minutes and cranked modifying all sorts of stuff in the tables and then it was done. -- I started up the web server on the new server and bang -- I have bugzilla 3.0.2 working with my old bugs, sweet - so far. Seems this method of moving forward is not mentioned or documented except in a few random posts on newsgroups as last ditch things to try - maybe I totally missed something, but it worked for me and this particular installation. We will see how it plays out once the users are directed to the new release URL.
4 comments:
The way you ended up doing it is the recommended way to do it, and is, in fact, what is suggested everywhere in the docs that it talks about upgrading. Since you didn't find it, it obviously wasn't clear enough, and we probably need to put references to it somewhere else to point people at it. :) What places in the docs did you look, and what words would have triggered "oh yeah, this is what I'm looking for" that we could have used to point you at the upgrading section?
Hi Dave, thanks for your comments. I looked at the distro unpacked tonight and tried to re-trace what I saw and didn't see when I took one of my stabs at upgrading - the chain of events was to look at QUICKSTART, glaze over at the 10 steps - ok that sounds easy, lets check out UPGRADING, oh, that points you at the docs directory, but wait; I don't need to look at that, there is a UPGRADING-pre-2.8 file, and I think - here is all the info I'm going to need because I'm upgrading from a version prior to 2.8 -- so I read the file and got lost in all the historical dates on when this and that was changed - there was no where in there saying, hey, if you are upgrading a really old version, you might consider dumping the DB and re-populating it on the other side, or pointing the reader at the html docs like the UPGRADING file does - which I guess may have had my answer; but never thought to go back and look at. Guess if I would have gone and looked at the HTML docs, I would have found the info I needed.
Ah the old "version numbers look like they have decimal points" trap. The period in the version number isn't a decimal point, it's just a position separator. 8 is older than 18.
There's a description of that on the website on the download page (the section "A word about version numbers"). I guess what we should do is put that description at the top of the UPGRADING-pre-2.8 file, too.
I did fall for the version number separator/decimal issue; seen that before, and now I'm the one.
Sounds good on putting a note in UPGRADING-pre-2.8 about version numbers. Even then, maybe something like: In addition to the information provided below, please make sure you view the HTML/SGL documentation at ... for full details on installation and upgrading?
Don't know how many folks get caught the way I did, but might save some of them.
Post a Comment