Posts Tagged 'major release'

Bugzilla 4.0 Released!

So, last week we released Bugzilla 4.0, which was pretty exciting. It had some awesome major new features, like the redesigned search page, automatic duplicate detection, autocomplete for user and keyword fields, and an enormously-enhanced WebServices interface.

In addition to all of these huge features, though, there were a lot of smaller improvements that were pretty awesome in and of themselves. The major, major features are so huge that it’s easy to miss how great some of the other changes were, so I wanted to take some time in this blog to talk about some of those “smaller” improvements that can be pretty significant for some users.

UI Improvements

In addition to the redesigned search page, one of the biggest UI improvements is the new “attachment details” page (log in to see the full functionality). If you do a lot of code review in your Bugzilla, or if you open up attachments frequently to comment on them, you’ll appreciate the new full-size comment box and the enormous textarea space available for commenting inline on text attachments.

Also, another really nice change is that when you forget to set a required field on bug entry, you’re notified before you leave the page, instead of having to submit the form and then go back to add any missing data. Bugzilla highlights the fields you missed and puts a clear message in bold red letters on the page so that you can see what you need to fill out. It even puts the page focus on the first box you need to fix, now.

On the Search page and the bug entry page, you can hover over the label of any field to get a description of what that field does. Your mouse cursor will even change to indicate the availability of help. This should be particularly useful to people who are new to Bugzilla.

When you do a “quicksearch” using the box in the header or footer, your search will still be there when you see the search results, now. This makes editing the search you just did a lot easier.

There is a “Calendar” widget for every single date/time field in Bugzilla now.

You can choose to have the “Add a new comment” box above or below the existing comments, when viewing a bug, now. (See your Preferences.)

Every command-line script of Bugzilla now prints any error in red (if this is possible in your terminal), to make it really clear that running the script did not succeed.

And of course, this is pretty obvious, but there are great new icons for the Home page, now.

Custom Fields

People have long asked for the ability to make certain custom fields “mandatory”–that is, when filing a bug, you have to fill those fields out, and after the bug is filed, those fields can never be empty. Bugzilla 4.0 now supports this–all you have to do is check a single checkbox in the Administration UI, and your custom field becomes mandatory!

You can see “Multi-Select” custom fields as a column in your search results (the bug list) now!

Almost every custom field in your system will now be available as an axis for Graphical Reports and Tabular Reports. (Actually, a whole lot of other built-in fields are now available, too!)

You can now represent relationships between bugs when using the “Bug ID” field.

You can now display custom fields only in a certain Component or only in a certain Classification.


Some people make really heavy use of the “Show my last search results” link, or the “First/Previous/Next/Last” links at the top of the bug page. In past versions of Bugzilla, doing a new search would entirely replace your “last search results”, meaning that “Show my last search results” and the “First/Previous/Next/Last” links would suddenly be working with a whole new set of bugs. Now Bugzilla “remembers” the last five search results for all logged-in users and does its best to give you the right list whenever you’re trying to navigate using those links on the bug page.

You can now search for attachments with specific flags on them, when using the Boolean Charts (which are now called “Custom Search”). Just specify a criteron for an attachment and a criterion for a flag in the same Chart.

Since almost the very first version of Bugzilla, you haven’t been able to search for a Product, Component, Target Milestone, etc. if its name contained a comma. Now you can!


You can get data from the Bugzilla JSON-RPC WebService using HTTP GET, now, which is a lot easier in many situations. Also, you can even call the JSON-RPC WebServices from another domain using JSONP, meaning that you can use data from an external Bugzilla on your webpage, straight from JavaScript!

Also, there are a ton of new WebService functions and parameters available. See the full list of WebService improvements for details. Probably the biggest one is the new Bug.update function that allows you to update existing bugs.


Loading pages in Bugzilla should now be much faster, particularly if it’s your first time visiting Bugzilla, since we have eliminated the need for the browser to download a large number of unnecessary CSS files.

If you’re using time-tracking, you don’t have to enter a comment just to enter Hours Worked anymore!

If you’re setting up the Inbound Email interface, you can set defaults for certain fields using command-line switches.

If you are using a localized version of Bugzilla and your terminal does not understand Unicode, all of Bugzilla’s command-line scripts will now attempt to output their messages in your terminal’s character set.

If you are running Bugzilla under suexec (usually meaning that you’re on shared hosting), now properly sets permissions on everything, meaning that all functionality of Bugzilla should now be working (including graphs and dependency trees).

Bugzilla now optionally supports sending the Strict-Transport-Security HTTP header for improved security on HTTPS installations.

If you are writing extensions, there are a ton of new hooks. The Extensions system is now capable of implementing the vast majority of possible extensions, particularly if you know a few tricks.

Future Plans

Now that 4.0 is released, we’re working on 4.2! Actually, we’ve been working on 4.2 for quite some time, and it already has some great new features, such as HTML bugmail and a new “tags” system that we’re implementing. We also expect to have a fully-redesigned Search backend that behaves consistently and intelligently for all searches while also performing considerably better than the current system does. There are already 100 enhancements marked as FIXED for 4.2, in fact! Check out that full list for details.

Currently our plan is to freeze for 4.2 on April 20, which would put our likely release date at some point in Q4 of 2011. Of course, depending on how many contributors we get, we could possibly release even earlier than that! Finding and fixing bugs in the trunk code is the fastest way to speed up our release process, so if you want to do that, see our development process for information on how to get our code and submit patches!


Bugzilla 3.6: Harder, Better, Faster, Stronger

Yesterday we released Bugzilla 3.6, which is exciting not just because of all the major new features, but also because of the tremendous number of minor improvements, and the speed with which we have been developing, lately. I’m going to talk a little bit today about some of those features and how we got out this major release so much more quickly than the earlier ones.

Harder: Improved Security in Bugzilla 3.6

In light of the recent attack against the Apache JIRA, I wrote a blog post describing how the same attack would have been impossible against Bugzilla, detailing just a few of Bugzilla’s enormous number of security features. I also figured that this would be an excellent time to talk about some of the new security features that Bugzilla 3.6 brings to the table:

  • Password lockout: If a user tries to guess their password and fails five times within 30 minutes, they will be locked out of their account for 30 minutes. Also, the administrators of Bugzilla (as specified in the maintainer parameter) will get an email notifying them of the lockout. This is all very important to protect against “brute-force password attacks”, where attackers just try passwords over and over until they find the right one. With this new feature, not only are brute-force attacks nearly impossible (it would take far too long to try enough passwords), but your Bugzilla administrators will also be able to stop any significant brute-force attacks after being notified by Bugzilla that they are occurring.
  • Longer minimum password length, no maximum password length: The minimum password length is now six characters. Granted, that’s not very long, but it’s far better than the default in earlier versions. If you want to increase the minimum, just edit the USER_PASSWORD_MIN_LENGTH constant in Bugzilla/

    Also, older versions of Bugzilla had a maximum password length. Bugzilla 3.6 has no maximum–your passwords can be, basically, infinitely long.

  • Improved SSL Support: For many years, Bugzilla has had the capability to force connections to redirect to SSL, for improved security of login data. Now, the SSL redirect code has been simplified and made even more secure, so that if you enable it, you’re guaranteed that every connection will have SSL enabled, and never interfere with the operation of other parts of Bugzilla.

Again, that’s just a few of the new features related to security. The full list of Bugzilla’s existing security features would be so long that nobody would finish reading the blog!

Better: Improved Usability

When you talk about a user interface, there’s a lot more to talk about than just how it looks. One of the most important aspects of UI is how much the user interface just natively makes sense to the people using it, and how easy it is for users to actually perform their tasks with it. In the past, Bugzilla has had a fairly bad reputation for its UI, but all that is starting to change, thanks to some research by Carnegie-Mellon University students, and a survey conducted by the Bugzilla Project with Mozilla’s assistance.

Now, the changes toward usability in Bugzilla 3.6 aren’t yet very dramatic. The huge, significant changes (like some fully-redesigned major UIs) are coming in the next release. But 3.6 does have some really interesting improvements in consistency and basic usability that we think you’ll like:

  • Consistent Language: If we’re talking about searching, we use the word “search” everywhere now. We don’t use a mixture of “query”, “find”, etc. Just “search”. Some other language was made more consistent like this, too.
  • Visual Indication of Mandatory Fields: When you go to file a bug, Bugzilla now visually shows you which fields are mandatory.
  • Javascript validation of attachment form: When creating a new attachment, we make sure that the attachment form values are valid with JavaScript, before the attachment gets submitted.
  • Visually Indicate Search Results’ Sort Order: When you do a search, you can now see the sort order, thanks to triangles next to the column headers.
  • Helpful Links after “Zaroo Boogs”: When there are no search results, some helpful links are displayed, offering actions you might want to take, including possibly filing a bug.
  • Improved and Simplified Quicksearch: The Search box at the top and bottom of each page is called the “quicksearch” box. In Bugzilla 3.6, this box now has full, clear documentation of its very powerful syntax, which has been extended and simplified, in preparation for its becoming the primary search system in Bugzilla for future releases.
  • Better Default Priority Names: Instead of the confusing P1-P5 (what’s highest, 1 or 5?), by default on a new Bugzilla installation, priorities are named “Highest”, “High”, “Normal”, “Low”, and “Lowest”.
  • Many Other Improvements: If you want the whole list of the changes we’ve made, see the Other Enhancements and Changes section of the Bugzilla 3.6 Release Notes. There are so many improvements to make Bugzilla “just work” that I can’t even list them all here.

Faster: Better Performance and Faster Release Cycles!

So, there’s definitely some improved performance in Bugzilla 3.6, especially in show_bug.cgi, the script that displays bugs (and it will be even faster in Bugzilla 3.8). But when I say “faster”, I think what’s most impressive about Bugzilla 3.6 is the speed with which we are releasing new major Bugzilla versions, nowadays.

Here’s the amount of time between Bugzilla versions, each with a summary of the size of changes compared to the previous major release:

  • 3.0: Released 1 year, 1 month after 2.22 was released.
  • 3.2: Released 1 year, 6 months after 3.0 was released.
  • 3.4: Released 8 months after 3.2 was released.
  • 3.6: Released 8.5 months after 3.4 was released.

As you can see, our last two releases have come out considerably more quickly than the two releases before them, and we’re starting to develop a consistent release-time pattern (about every 8 months, though we’d like to get it down even lower). However, what you can’t see in the above table is that 3.6 has 1.5x more changes than 3.4 had, despite the fact that releasing 3.6 only took half a month longer!

“So,” you might ask, “what’s the secret to these consistent schedules and ever-increasing productivity?” Well, there have definitely been a lot of improvements to Bugzilla’s community processes and infrastructure, and that’s probably the reason for the productivity increase. But the biggest factor in the consistency of our new schedule is that we have a new development policy: never freeze the trunk.

Yep, that’s right. We never freeze. There are no long, two-month periods where nobody can add new features, anymore. Not only was that slowing down our development speed enormously, but it was really killing community enthusiasm–it’s much more fun to write new features than it is to fix bugs, but when your new feature won’t be reviewed for the next two months, it just makes you want to not contribute at all.

So, instead of freezing, we branch immediately at the point where we normally would have frozen. The branch gets stability fixes, and the trunk gets new features. To make this all clearer, let me explain how the whole release process for Bugzilla 3.6 worked:

  1. On November 29, 2008, we released Bugzilla 3.2.
  2. Two months later, we created the 3.4 branch in CVS. Stability fixes for making 3.4 releasable went on to the branch, and work on Bugzilla 3.6 started immediately, on the trunk.
  3. Two months after the release of Bugzilla 3.4, we branched for 3.6, and work started immediately on the trunk for 3.8.

So yes, this means that most of the time, we’re focusing on adding new features to the trunk and improving stability on the branch, so there’s a split of resources. But it turns out that actually, this makes releases go faster, not slower. People fix bugs on the branch, because they have a motivation to see their work released. People develop features on the trunk, because writing new features is fun.

So that’s our new policy: never freeze, just branch. I’d recommend that every project try it out, personally. It’s worked wonders for us.

Stronger: Extensions and Other Improvements

This is definitely the best release of Bugzilla we’ve ever done, and there’s so much to talk about, even with all the stuff that I’ve already covered above. The official release announcement covered the new Extensions system pretty well. I do have to say here, though, that Extensions really are great, and I think that with all the enthusiasm we’re seeing about them from the community, we can pretty much guarantee that Bugzilla Extensions are the future, in terms of seeing massive new functionality for Bugzilla installations everywhere.

In addition to Extensions, I also wanted to talk a bit about some new features that are particularly exciting to me, and that I think you might like as well:

  • The “Browse” interface is great for small-to-medium-sized projects, where you just want to see a list of every open bug in a component.
  • The new JSON-RPC WebServices interface is pretty exciting, but even more exciting is that in future versions of Bugzilla, it will allow secure cross-domain access to Bugzilla’s data, allowing “web mash-ups” of Bugzilla data!
  • The new system for migrating from other bug-trackers is a big deal, because it means that once somebody implements an importer for a particular system, that importer will keep working for all the future versions of Bugzilla. So, slowly, over time, we’re going to build up an awesome collection of importers for other bug-tracking systems.
  • You can see Flags in search results! If you use Flags, this is pretty big.
  • If you have multiple languages installed in your Bugzilla, users can simply click to pick the language they want to view Bugzilla in–you don’t have to switch your browser settings to switch languages, anymore.
  • Field values for global fields (not per-product fields yet, unfortunately) can be “disabled” so that they don’t show up as selectable on bugs anymore! This allows for cleaning up old values in the Platform field, the OS field, the Resolution field, etc.
  • prints out its errors in a special color so that administrators will actually notice that there’s a problem.

And that’s just the features that I wanted to point out in case you missed them in the release notes! The full list of new features in 3.6 is astounding, go check it out!


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.