Blog

Want to always keep up-to-date with Bugzilla news? Subscribe to announce@bugzilla.org, a read-only mailing list where we'll post announcements about new versions of Bugzilla and security advisories.

Browse Archives »

You can also see what's going on in the project by looking at the notes of, or watching the video of, our monthly developer meetings.

Loading the upcoming event

24. June 2010

Release of Bugzilla 3.2.7, 3.4.7, 3.6.1, and 3.7.1

by Bugzilla Team

Today we have four new releases! One new development snapshot (3.7.1), two new stable releases (3.6.1 and 3.4.7) and one update for the legacy 3.2 branch, 3.2.7.

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 3.6.1 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 3.4.7 is a security and bug-fix update for the 3.4 branch. This is the last bug-fix release for the 3.4 series–after this, it will only get new updates if there are security issues discovered in the 3.4 series.

Bugzilla 3.2.7 is a security update for the 3.2 branch:

Bugzilla 3.7.1 is an unstable development release, with a ton of exciting new features and UI improvements. However, this release has received no testing from the Bugzilla Project, so it should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

For details on what’s new in this development release and what’s going on with the Bugzilla Project, see our latest Bugzilla Update.

24. June 2010

Release of Bugzilla 3.2.7, 3.4.7, 3.6.1, and 3.7.1

by Max Kanat-Alexander (mkanat)

So, today we had a bunch of releases. They are good. They fix stuff! Fixed stuff is good. :-)

Now, I could pretty much end the blog post there, but there is one…tiny…extra…thing to talk about. If you were paying attention, you might have noticed that the 3.7.1 release says that it’s leading up to Bugzilla 4.0! Yes, that’s right, the next major release of Bugzilla will be 4.0, and here’s a bit about it:

Why 4.0?

So what is it that makes this release worthy of being called 4.0? Well, the biggest thing is that there have been major UI improvements. The biggest one is that the Advanced Search page has been fully redesigned. You can see it at our test site. It’s going to get better than that, too. Also, if you review a lot of patches, you will probably appreciate the new attachment details UI (log in to see the full feature set).

Bugzilla 4.0 will also have cross-domain WebServices support, via JSONP. As a part of that, the JSON-RPC WebServices interface can also now be accessed using HTTP GET and a simple query string in the URL, instead of having to POST a JSON object.

Also in the area of WebServices, we’re planning to have our most-requested WebService function implemented, Bug.update, so that you can update all the attributes of a Bug via the WebServices. There may be other good WebServices improvements which make 4.0, too.

Also, a great feature for installations that get a lot of bugs is the new Automatic Duplicate Detection. To try it out, go to file a bug on our test installation, type a few (real) words in to the Summary field, and then click out of it.

We are also planning on changing the default statuses, based on our 12 years of experience since Bugzilla was first open-sourced. The current status workflow is simple and broadly applicable, but it is ambiguous or less-than-useful in some ways: for example, a NEW bug may not actually be NEW–it’s just not being worked on. And then what does ASSIGNED really mean? Does it mean that somebody is working on the bug, or just that it’s been assigned to somebody (which you can already tell from the Assigned To field)? So, to resolve these issues, the new workflow will be even simpler: UNCONFIRMED -> CONFIRMED -> IN_PROGRESS -> RESOLVED -> VERIFIED. Installations that are upgrading will keep the old workflow by default, although there will be a script included to convert them to the new workflow, if they want.

Features Already In 3.7.1

3.7.1 already has the new Search UI and the new Attachment Details UI, although further improvements to the Search UI are coming in later development releases. 3.7.1 also has automatic duplicate detection and JSONP support for the JSON-RPC WebService.

Some of the other new features and changes in 3.7.1 are:

  • There is AJAX auto-completion of usernames in the CC, Assignee, and QA Contact boxes.
  • The First/Last/Next/Prev and the “Show my last search results” links at the top of a bug now work with multiple searches, so doing a new search won’t “clobber” your old list.
  • Bug ID custom fields can now represent relationships, much like “Blocks/Depends On” do now.
  • You can now add Hours Worked to a bug without having to comment.
  • There are now calendar widgets on every date field in the UI.
  • The Voting system and the Bug Moving system have been moved into being extensions, and at some point will be maintained separately from the main Bugzilla codebase (though they still ship with Bugzilla, for now).
  • email\_in.pl now takes command-line arguments that allow you to specify defaults for field values, or override the field values specified in the incoming email.
  • Multi-select custom fields can now be columns on bug lists.
  • There is a new user preference for whether the “Additional Comment” box should show up before or after the existing comments.
  • In the code, there is a new function $bug-\>set\_all, which takes a bunch of arguments and updates a bug doing all the updates in the proper order, making it extremely easy for custom code to update bugs.
  • The Bugzilla/Search.pm file (which implements the searching logic in Bugzilla) has been majorly refactored to be much simpler to understand and customize.
  • When you do a quicksearch, the quicksearch boxes in the header and footer will contain your last search.
  • You can now restrict the values and visibility of custom fields by the value of the Component field.
  • Custom fields can now be marked as mandatory (that is, they must have a value).
  • The “fields.html” page now contains help for every single bug field in Bugzilla, and the fields display the help when you hover over their names, on enter\_bug.cgi.
  • There are a lot of great new code hooks, including ones for adding new columns and validators to objects, and another for modifying bug field permissions (so you can make certain fields read-only for certain users, using a hook).
  • Bugzilla can now be installed using Strawberry Perl, on Windows.
  • Comments are no longer manually word-wrapped at 80 columns before being sent to the browser–they are just word-wrapped in the browser.
  • Any time checksetup.pl throws an error, it will make it red to make it clearer.
  • YUI has been updated to 2.8.1, and Bugzilla now contains almost all of YUI, so all YUI features are available to customizers.

Do remember, though, that this is an unstable release. It may have bugs. They might be really bad bugs. We have no idea, because we haven’t tested this release at all. If it pokes your best friend in the face when you file a new bug, don’t blame us–we warned you. :-)

The Plan

Right now we expect the 4.0 release to happen some time around the end of this year. To make this target, we’ll definitely need help with QA, so if you want to help out with Bugzilla, see if you can find/fix some bugs in 3.7.1, and also if you want, you can help out the QA Team write automated tests for 4.0!

13. April 2010

Release of Bugzilla 3.6!

by Bugzilla Team

Today the Bugzilla Project is pround to announce the release of the next major version of Bugzilla: 3.6! Bugzilla 3.6 has a lot of exciting new features for Bugzilla users and administrators, including migration from other bug-tracking systems, a simple “Browse” interface for browsing open bugs in a system, and some usability improvements resulting from a scientific usability study conducted on Bugzilla.

Bugzilla Extensions

One of the most exciting new features of Bugzilla 3.6 is Extensions. These are self-contained files that you can “drop in” to a Bugzilla installation to add new features or change Bugzilla’s behavior, without modifying any existing code! Anybody can write and distribute their own Extension–Bugzilla 3.6 includes very detailed documentation on how to write and distribute Extensions, and even includes a script that will set up the framework of a new Extension for you so that you can get right to coding.

Bugzilla 3.6 ships with one simple Extension that you can enable, and there are also already a few publicly-available Extensions for Bugzilla 3.6, that any Bugzilla 3.6 installation can install to add new functionality to their system.

Some developers have been using pre-release versions of the new Extensions system in Bugzilla 3.6, and here’s what they have to say about it:

  • Bugzilla Extensions really help me to do my customizations, giving me flexibility and reducing the impact in the tool’s core. Congratulations Bugzilla team! -Tiago Mello, IBM Linux Technology Center.
  • With the new Extensions system, I can change almost any part of the UI without having to worry about upgrades. Plus, the Extension installation directions are super simple! Making usability tweaks for Bugzilla just got a lot easier. -Guy Pyrzak, UI Designer
  • Writing Bugzilla Extensions is some of the most fun I’ve had programming in years. -Max Kanat-Alexander, Assistant Project Lead, Bugzilla Project.

We look forward to seeing what you do with the new Extensions system!

End of Life: Bugzilla 3.0.x

With the release of Bugzilla 3.6, the Bugzilla 3.0.x series has reached End Of Life. This means that there will be no new releases in the 3.0.x series, even if serious security issues are discovered in 3.0.x. Bugzilla 3.0.11 is the last Bugzilla 3.0.x version that will be released. We strongly recommend that any Bugzilla installation still running Bugzilla 3.0.x promptly upgrade to Bugzilla 3.6.

08. March 2010

Release of Bugzilla 3.6rc1 and 3.4.6

by Bugzilla Team

Bugzilla 3.6rc1 is our first Release Candidate for Bugzilla 3.6. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.

If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 3.6 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.

Since this is a Release Candidate, it includes Release Notes and a listing of New Features. Make sure to check out the “Other Enhancements and Changes” section in particular–there are a lot of great improvements listed in there!

Bugzilla 3.4.6 is our latest stable release. It contains various useful bug fixes:

01. February 2010

Release of Bugzilla 3.0.11, 3.2.6, 3.4.5, and 3.5.3

by Max Kanat-Alexander (mkanat)

Okay! So we’ve got four releases today! Bugzilla 3.4.5 is a bug-fix release, it’s got some good bug fixes and small improvements. Bugzilla 3.2.6 and 3.0.11 are only fixing a small security issue. Everything released today has security fixes, some of them could actually be important for your installation, depending on how you use Bugzilla. The Security Advisory has details.

We also have a development release, 3.5.3. We’re feature-frozen now, which means that there won’t be any major new features until 3.6 is released, but there still are a lot of bug fixes that need to be done, so it’s not stable yet. Here are some of the new features since 3.5.2:

  • If your Bugzilla is behind a proxy, you can tell it to accept X-Forwarded-For as the end user’s IP address, when the request comes from the proxy.
  • The “Required” parameters section now only lists actually required parameters. Other parameters have been moved to the “General” or “Advanced” section.
  • When installing Bugzilla, the “maintainer” parameter will automatically be set to the admin user you create during checksetup.pl.
  • “votestoconfirm” is now unrelated to the existence of the UNCONFIRMED status in a product. There is instead a checkbox to enable UNCONFIRMED.
  • QuickSearch has had a syntax overhaul to make it much simpler and also able to search more fields. Unfortunately, the documentation for this change didn’t make it into 3.5.3, but it will be in 3.6 at the latest.
  • New WebService function: Bug.fields.
  • The show_bug UI has had a few small changes.
  • The “milestoneurl” feature of a product has been removed.
  • The strings at the top of comments that say that you created or commented on an attachment are now localizable.
  • User accounts are now locked out on a particular IP for 30 minutes if they fail to log in 5 times from that IP.
  • There’s a new “Browse” interface–it’s actually just an updated interface to describecomponents.cgi, but it’s linked from the toolbar as “Browse” now.
  • You can now add attachments to a bug when using email_in.pl.
  • enter_bug.cgi now indicates in the UI which fields are mandatory.
  • mod_perl should be working on Windows now, though it hasn’t received a lot of testing from us.
  • There’s a whole awesome new Extensions system for Bugzilla (see below for more about that).

The New Bugzilla::Extension System

One of the biggest new things in 3.5.3 is the new Bugzilla::Extension system, which is a complete overhaul of how extensions work. The new extensions system is consistent, fast, and fully documented. It makes it easy to create and distribute extensions. It’s even possible to distribute them via CPAN. And for people who were using the old system, the new system comes with a script to do some automatic conversion of older extensions.

If you want to know more about it, the Bugzilla::Extension documentation contains everything you need to know to write an extension. And you can get started quickly by using the extensions/create.pl script in Bugzilla itself.

Moving to Bzr

Very soon, Bugzilla development will be moving away from CVS and onto Bazaar (called “bzr” for short). CVS will still continue to work as a read-only repository though, so you’ll still be able to update your installations and check out via CVS if you want to. More details about bzr and how Bugzilla will use it will be available after we switch.

The Road to Bugzilla 3.6

The next steps on the road to Bugzilla 3.6 are for us to finish working on all the current blockers, then to write some QA scripts for 3.6, then to write the release notes, and then to do some release candidates, and then to release! The Bugzilla Calendar has more detail on the current estimated dates of release candidates and final release.

And that’s it for the Bugzilla Update for this time!

31. January 2010

Release of Bugzilla 3.0.11, 3.2.6, 3.4.5, and 3.5.3

by Bugzilla Team

Today we have four new releases:

Bugzilla 3.4.5 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 3.2.6 is a security update for the 3.2 branch:

Bugzilla 3.0.11 is a security update for the 3.0 branch:

Bugzilla 3.5.3 is our latest unstable development release. We are now feature-frozen for 3.6, so though there will be a few functional changes between now and the final release, this is mostly what 3.6 will look like when it comes out. As usual with development releases, this release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features thatthe next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

For details on what’s new in this development release and what’s going on with the Bugzilla Project, see the latest Bugzilla Update.

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

18. November 2009

Release of Bugzilla 3.4.4 and 3.5.2

by Bugzilla Team

We are releasing Bugzilla 3.4.4 and Bugzilla 3.5.2 today, primarily to fix one security issue. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 3.4.4 is our latest stable release, and contains the security fix in addition to a few minor bug fixes:

Bugzilla 3.5.2 contains the security fix for the 3.5.x series. As usual, this development release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback. So if you find a bug in this development release (or you don’t like how some feature works) please tell us.

05. November 2009

Release of Bugzilla 3.5.1, 3.4.3, and 3.0.10

by Bugzilla Team

Today the Bugzilla Project has three new releases, 3.5.1, 3.4.3, and 3.0.10!

Bugzilla 3.4.3 is our latest stable release. It contains various useful bug fixes:

Bugzilla 3.0.10 fixes one bug with the WebService introduced in Bugzilla 3.0.9:

Bugzilla 3.5.1 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

For details on what’s new in this development release and what’s going on with the Bugzilla Project, see The Bugzilla Update.

05. November 2009

Release of Bugzilla 3.4.3, 3.0.10, and 3.5.1

by Max Kanat-Alexander (mkanat)

Here we are in our new home on Wordpress.com! This should be generally easier to keep up with and is a better, more “official” place than my personal blog. As of now, the Bugzilla “Status Update” page is dead and this is the official location of Bugzilla status updates.

For the first post on the new blog, I’ve released Bugzilla 3.4.3, Bugzilla 3.0.10 and Bugzilla 3.5.1. The Release Announcement has all the details about the two stable releases. What we’re going to cover in this update is 3.5.1, our development release, which has a ton of new features and major improvements.

I’m only going to cover things that are new since our last Bugzilla Update, so if you want to know the whole history of Bugzilla 3.5 (what will become 3.6), read the prior updates about Bugzilla 3.5.

Bugzilla 3.5.1

I’d like to remind everybody that 3.5.1 is unstable. It had little to no testing at all, so shouldn’t be used in a production environment. You should test it out and report bugs or make suggestions, though! Now is the time to suggest changes in our major new features. By the time we get to the Release Candidate stage, it’s often too late to make major changes! So if you want any major changes to how things work in 3.5.1, let us know soon!

The Bugzilla Migration Framework

One of the biggest new features in 3.5.1 is migrate.pl, a script that allows easy migration from a different bug-tracking system to Bugzilla.

The exciting news is that this makes it very easy to write new migrators to migrate from any bug-tracking system to Bugzilla.

Also, this makes migration a first-class part of Bugzilla, not part of contrib/. This means that we will maintain the migration framework, and the migrators themselves, and if they break, that’s a regression.

The first migrator implemented is for GNATS. The code is in Bugzilla/Migrate/GNATS.pm, if you want to see what a migrator looks like.

The migration framework has the following features:

  1. It is non-destructive. You can migrate into an existing Bugzilla installation!
  2. It’s relatively easy to implement new migrators for systems. Basically all you have to do is provide arrays of hashes describing the products, users, and bugs in your bug-tracker, and Bugzilla::Migrate does the rest of the work. It even contains a facility to translate values from the old bug-tracker to Bugzilla, and allows the end user to specify how that translation should work.
  3. It is capable of doing a “dry-run” of your migration, so that you can see if everything is going to go well before actually committing anything to the database.

We would love to see new systems implemented to migrate from! The review requirements for new migrators are slightly relaxed–we will believe you when you say that they work, as long as they are coded well and follow the Bugzilla Developers’ Guide.

Also, if anybody wants to provide me (or the Bugzilla project in general) a dump of a large working installation of a bug-tracker, that will also help people who want to write a migrator.

Finally, this makes it much easier for consultants to write migrators, so if you were thinking of hiring a Bugzilla Consultant to help you migrate to Bugzilla, now is an ideal time!

Improvements in 3.5.1 for Administrators

  • The default priority values are now human-readable words instead of P1, P2, etc.
  • I spent a lot of time making checksetup.pl faster at updating Bugzillas, particularly older Bugzillas. If you wanted to upgrade in the past, but you were worried that running checksetup.pl would cause too much downtime, I’d suggest trying an upgrade to 3.5.1 and see how it goes.
  • checksetup.pl now displays important messages in red.
  • The code that optionally converted BMPs to PNGs has been made into an extension, and is disabled by default. If you want to enable it, delete extensions/bmp_convert/disabled and run checksetup.pl. In the future, this extension will be removed from Bugzilla and shipped separately.
  • checksetup.pl now displays warnings when it fails to fix permissions on files, and dies with an error if it fails to create a directory.
  • checksetup.pl no longer dies when it cannot delete the data/template directory–instead it moves the directory out of the way.
  • duplicates.cgi now gets all of its information directly from the database, meaning that it no longer stores huge numbers of files in the data/ directory, and no longer requires that collectstats.pl be run nightly in order for it to work.
  • ssl options are simpler–there is now a parameter called ssl\_redirect which, if on, will always redirect users to the SSL version of your Bugzilla.
  • The loginnetmask parameter has been removed. Users are always allowed to use their cookie from any IP address, unless they choose to restrict it to their IP address when they log in.
  • email\_in.pl now runs in taint mode for increased security.

Improvements in 3.5.1 for Users

  • There are now arrows on the bug list which indicate what direction each column is currently sorting in.
  • There is no longer a maximum length for passwords.
  • request.cgi now groups the Product drop-down by Classification, if you are using Classifications.
  • Users are now automatically logged in after changing their password.
  • You can now load a saved search as the search for a New Charts series.
  • You can now see flags on a bug as part of search results.
  • Dependency Graph arrows now go the other direction, which seems to make more sense.
  • When creating an attachment, you will now be warned via a popup if you attempt to submit it without a description (instead of only being warned with an error after submitting the attachment).
  • You can now make comments on attachments even if you can’t edit their properties.
  • Links are now more visible, in the Dusk skin.
  • If you are logged out or don’t have permissions to edit the properties of attachments, you will now get a read-only page when viewing an attachment’s details.
  • If a user in the “insider group” adds a private comment and also makes public changes, an email about those public changes will now be sent to users who can see them. (In the past, adding a private comment entirely prevented email to users who were not in the “insider group”.)

Improvements in 3.5.1 for Customizers and Extension Authors

  • There is now a $bug-\>set\_flags and $attachment-\>set\_flags, which are used to create and update flags on bugs and attachments.
  • Bugzilla::Template::quoteUrls now has a hook that should be pretty easy to use, if you want to adjust how Bugzilla highlights comments. (The hook is bug-format\_comment.)
  • There is now a hook for page.cgi, which allows extensions to add their own new pages to Bugzilla.
  • You can now use Bugzilla-\>feature to detect if the modules for a certain feature are installed, instead of having to attempt to load those modules yourself.
  • The bug/show.html.tmpl template now requires far fewer variables in order to display it.
  • There is now a hook that allows you to modify an attachment’s data before it goes into the database.
  • Hooks can now call exit safely under mod_perl.
  • There is now a template-before\_process hook which allows you to modify variables before $template->process is called. It will be improved before Bugzilla 3.6 is released to allow for modifying variables before any template is ever loaded..
  • There are many other new hooks.
  • There is now a basic infrastructure in place that will allow localizers to translate field values for every field on display.

Upcoming Improvements For Bugzilla 3.6

There is a lot of exciting stuff on the horizon for Bugzilla 3.6, with patches written and awaiting review before they become an official part of Bugzilla:

  • Adding attachments to a bug by email (via email\_in.pl).
  • Tons of new hooks. Extensions are becoming very powerful.
  • QuickSearch is becoming simplified and improved, and getting new documentation. It will be merged into the Simple Search page, as well.
  • WebService clients will be able to authenticate by passing the arguments Bugzilla\_login and Bugzilla\_password to any method.
  • The default statuses and status workflow are going to change, based on 10 years of Bugzilla experience.
  • Some UI improvements for the bug editing page are on the way.
  • The WebService will respect taint mode, for improved security.
  • You will be able to specify groups for a bug when creating it via email\_in.pl or the Bug.create WebService function.
  • There is going to be a Bugzilla::Comment object in the code to assist with loading and creating comments.
  • Users who fail to guess a password too many times will be locked out of their account for a certain amount of time.

Also, we expect Bugzilla 3.8 (but not Bugzilla 3.6) to support MS-SQL Server as a backend database.

Whew!

That was quite a Bugzilla Update! As you can see, the Bugzilla team is busier and more productive than ever, working to make you a better bug-tracker! One thing we always need, though, are more contributors! See our Contribute Page for more details on all the ways you can help out Bugzilla–you don’t just have to be a programmer!

Until next time, happy bug-tracking!

11. September 2009

Release of Bugzilla 3.4.2, 3.2.5, and 3.0.9

by Bugzilla Team

Today the Bugzilla Project is releasing Bugzilla 3.4.2, 3.2.5, and 3.0.9. All of these releases contain a very important security fix. See the Security Advisory for details. If you are running 2.23 or newer, you should upgrade immediately. If you are unable to update to the latest version, then please apply the patches for the issues as described in the Security Advisory.

Bugzilla 3.4.2 is our latest stable release. In addition to the security fix, it contains various useful bug fixes and minor improvements:

Bugzilla 3.2.5 is a security update for the 3.2 branch which also contains a few minor bug fixes for the 3.2 series:

Bugzilla 3.0.9 is a security update for the 3.0 branch: