Release of Bugzilla 3.4! (Bugzilla Update: July 28, 2009)
I have just posted the tarballs and done the website updates for Bugzilla 3.4! This means that we're out, released, ready to download, install, and go!
Bugzilla 3.4 is the best release of Bugzilla we've ever made. It has tons of great new features, the most exciting of which are listed in the release announcement, so I won't repeat them here. But you should go download it!
The Story of Bugzilla 3.4
As you look through the New Features list of Bugzilla 3.4, you may notice that it fixes tons of major issues that Bugzilla has had since its beginning. For example, we fixed the biggest performance problem in Bugzilla--sending emails when a bug is updated--and we finally hide email addresses from logged out users, to prevent spam. And that's just a tiny taste of what's new. Really, check out the New Features list to see everything.
But you may be asking yourself, why the sudden fixing of all these issues, and why didn't we do it before?
Well, that's an interesting story! From about 2003 to 2008, we spent nearly all of our time fixing up the code of Bugzilla. It needed a lot of refactoring, and we really did it--five years of it! We added new features at the same time as we refactored (remember, Bugzilla 3.0 had the largest number of major new features of any release we've ever done, and we were still refactoring), but the refactoring was our main focus. But finally, finally, with the release of Bugzilla 3.2, we fixed up one of the last major code issues in Bugzilla--we changed process_bug.cgi into a nice, simple series of steps that use Bug objects to do all their work.
After all this was done, we could finally take the time to look around and say, "What next?"
Well, what happened next was what led to such a great Bugzilla 3.4 release. First, I declared a new method of prioritizing work on the Bugzilla Project that put major issues of our current users as higher priority than adding new features for our prospective users. This led to us looking at the major survey items from our 2008 Bugzilla Survey and doing something about all the major requests that we could address immediately. Then we went through and looked at the bugs with the most votes on them, and did something about a lot of them.
And that, pretty simply, led to us addressing the things that people most wanted, and that we could actually prove that they wanted (because we had great survey feedback, or a lot of votes from individuals on our bugs).
Now that we've addressed so many of the individual things that users wanted, look to Bugzilla 3.6 and later for some big user interface and usability improvements--we have the results of extensive usability research that was done on Bugzilla, thanks to students from Carnegie-Mellon University, and we are already addressing the list of issues that that research generated.
Warning for WebService Clients: Changes Since Bugzilla 3.4rc1
Anybody who has been writing WebService clients against the 3.3.x or 3.4rc1 releases should know that we changed a few things in the API between 3.4rc1 and 3.4:
Bug.comments now takes an "ids" parameter instead of a "bug_ids" parameter (we just renamed the parameter to be consistent with out other WebService functions). Also, it will now throw an error if you try to add a private comment and you don't have the permissions to do so. (Previously it just added a public comment if you didn't have the permissions to make a private comment.)
Bug.history now returns its result in a completely different format, one which is more consistent with the format that Bug.comments and Bug.get use.
Progress on Bugzilla 3.6
Since our last Bugzilla Update just a few weeks ago, we've fixed several usability issues, sped up quicksearch, and added the ability to disable field values in global drop-down fields (without deleting the value).
Coming up soon, expect to see a lot of new WebService methods--there's been a lot of activity in adding WebService code, lately.
The End of Bugzilla 2.x
With this release, we EOL'ed Bugzilla 2.22, the last remaining supported 2.x release. That means that only 3.x releases are supported now. It's kind of wild to think that Bugzilla 2.x is "dead", after nearly ten years, and so much of my personal time spent on it. I started working on Bugzilla back in the 2.18 days, and I was pretty much the release manager for three major 2.x releases--2.18, 2.20, and 2.22. It's amazing to think that those releases were so long ago that now the very last one has reached the end of its support life. It's all Bugzilla 3.x (and hopefully 4.x soon) from here on out, my friends! :-)
Subscribe to the Bugzilla Update
There is an Atom feed that you can subscribe to and read in your RSS reader, for just the Bugzilla Update.
Bugzilla 3.4 is the best release of Bugzilla we've ever made. It has tons of great new features, the most exciting of which are listed in the release announcement, so I won't repeat them here. But you should go download it!
The Story of Bugzilla 3.4
As you look through the New Features list of Bugzilla 3.4, you may notice that it fixes tons of major issues that Bugzilla has had since its beginning. For example, we fixed the biggest performance problem in Bugzilla--sending emails when a bug is updated--and we finally hide email addresses from logged out users, to prevent spam. And that's just a tiny taste of what's new. Really, check out the New Features list to see everything.
But you may be asking yourself, why the sudden fixing of all these issues, and why didn't we do it before?
Well, that's an interesting story! From about 2003 to 2008, we spent nearly all of our time fixing up the code of Bugzilla. It needed a lot of refactoring, and we really did it--five years of it! We added new features at the same time as we refactored (remember, Bugzilla 3.0 had the largest number of major new features of any release we've ever done, and we were still refactoring), but the refactoring was our main focus. But finally, finally, with the release of Bugzilla 3.2, we fixed up one of the last major code issues in Bugzilla--we changed process_bug.cgi into a nice, simple series of steps that use Bug objects to do all their work.
After all this was done, we could finally take the time to look around and say, "What next?"
Well, what happened next was what led to such a great Bugzilla 3.4 release. First, I declared a new method of prioritizing work on the Bugzilla Project that put major issues of our current users as higher priority than adding new features for our prospective users. This led to us looking at the major survey items from our 2008 Bugzilla Survey and doing something about all the major requests that we could address immediately. Then we went through and looked at the bugs with the most votes on them, and did something about a lot of them.
And that, pretty simply, led to us addressing the things that people most wanted, and that we could actually prove that they wanted (because we had great survey feedback, or a lot of votes from individuals on our bugs).
Now that we've addressed so many of the individual things that users wanted, look to Bugzilla 3.6 and later for some big user interface and usability improvements--we have the results of extensive usability research that was done on Bugzilla, thanks to students from Carnegie-Mellon University, and we are already addressing the list of issues that that research generated.
Warning for WebService Clients: Changes Since Bugzilla 3.4rc1
Anybody who has been writing WebService clients against the 3.3.x or 3.4rc1 releases should know that we changed a few things in the API between 3.4rc1 and 3.4:
Bug.comments now takes an "ids" parameter instead of a "bug_ids" parameter (we just renamed the parameter to be consistent with out other WebService functions). Also, it will now throw an error if you try to add a private comment and you don't have the permissions to do so. (Previously it just added a public comment if you didn't have the permissions to make a private comment.)
Bug.history now returns its result in a completely different format, one which is more consistent with the format that Bug.comments and Bug.get use.
Progress on Bugzilla 3.6
Since our last Bugzilla Update just a few weeks ago, we've fixed several usability issues, sped up quicksearch, and added the ability to disable field values in global drop-down fields (without deleting the value).
Coming up soon, expect to see a lot of new WebService methods--there's been a lot of activity in adding WebService code, lately.
The End of Bugzilla 2.x
With this release, we EOL'ed Bugzilla 2.22, the last remaining supported 2.x release. That means that only 3.x releases are supported now. It's kind of wild to think that Bugzilla 2.x is "dead", after nearly ten years, and so much of my personal time spent on it. I started working on Bugzilla back in the 2.18 days, and I was pretty much the release manager for three major 2.x releases--2.18, 2.20, and 2.22. It's amazing to think that those releases were so long ago that now the very last one has reached the end of its support life. It's all Bugzilla 3.x (and hopefully 4.x soon) from here on out, my friends! :-)
Subscribe to the Bugzilla Update
There is an Atom feed that you can subscribe to and read in your RSS reader, for just the Bugzilla Update.