Why did it take Bugzilla 9 years to get from version 2.0 to 3.0?

Bugzilla 3.0 was released last night!

I was too tired last night to post anything, and I’d be remiss if I didn’t post something today. 🙂 All the good information is on the release announcement on bugzilla.org.

It was almost 9 years ago when Bugzilla 2.0 was released. We made a big deal about that in the release announcement, and since then I’ve seen the question asked “Why did it take 9 years to get from version 2.0 to version 3.0?”

Well, one of the little known secrets (some of the old-timers might remember this) is there was another attempt to create Bugzilla 3.0 several years ago. The original idea was to start over from scratch, and design with a completely object-oriented back-end in mind, with complete separation between the program logic, and the user presentation, allowing many different types of front-ends to potentially talk to the back end. You can see the remnants of this project in LXR. Many people knew of this project at the time, and since Hixie had already taken the version 3 number, we didn’t want to confuse anyone, so the existing codebase continued to evolve adding numbers to the minor version component of 2.x, even though several of the 2.x releases had fairly major new features in them.

Bugzilla has been using the even/odd version numbering scheme, where released versions always have an even minor version number, and development versions always have an odd number. So since 2.0 came out, we’ve had 2.2, 2.4, 2.6, 2.8, 2.10, 2.12, 2.14, 2.16, 2.18, 2.20, and 2.22 using the 2.x versioning scheme. Almost every one of these had major feature improvements. Something else that happened along the way: The vast majority of the design goals from Hixie’s Bugzilla 3 proposal got met along the way, by iterative development of the existing codebase. Bugzilla now uses a templating system for any output going to end-users (be that email or HTML pages, or XML, CSV, RSS, etc). The majority of the back-end code has been refactored into a comprehensive set of Perl modules that do all the dirty work of interacting with the database. The vast majority of the “sloppy code” was rewritten by necessity over the last 5 years in order to make Bugzilla work in Apache’s mod_perl.

So this last summer, some of us realized that Bugzilla really had progressed a long ways, and was certainly deserving of a major version bump. A bunch of us sat down at one of our Bugzilla team meetings and put together a roadmap for what it would take to make us all agree to call it Bugzilla 3.0. By this point, the original Bugzilla 3 project spearheaded by Hixie had long ago died off, and hardly anyone remembered it, so we decided there was no need to worry about confusion (otherwise we would have called this Bugzilla 4.0 instead 🙂 ).

It’s been discussed elsewhere, but very few open source developers ever want to do complete rewrites. Everyone likes scratching their own itch, and usually that’s one or two features they’re missing, and it’s much easier to make changes to existing code than it is to write something completely new from scratch. This little adventure to obtain Bugzilla 3.0 is a good example of that. Hixie’s design for Bugzilla 3 that was posted 6 years ago last week was really pretty good. But very few people joined him to work on it, and the folks that were working on it eventually didn’t have time for it and it died. But most folks understood it was the right way to go, and the Bugzilla 2 codebase eventually evolved into that in little tiny pieces over the course of 5 to 6 years.