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

27. January 2014

Release of Bugzilla 4.5.2 and 4.4.2

by Bugzilla Team

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

Bugzilla 4.5.2 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.

25. November 2013

Bugzilla considering moving to git

by Bugzilla Team

The Bugzilla Project is currently considering moving our source code repository from Bazaar (bzr) to git.  Part of the impetus for this is that Mozilla is trying to get out of the business of hosting every version control system known to man (which they currently do, or close to it anyway) and bzr is one of the low-hanging fruit (Bugzilla is the only Mozilla project using it).  There’s also a lot of feeling out there that mirroring to GitHub may make contributions easier for new contributors. The general consensus on the thread so far is that we should do it; the main point of contention is how long to keep it mirrored in bzr after it moves.

What’s your take on it?  We’d appreciate anyone who currently works on Bugzilla or is contemplating it to join in on the discussion.

The main discussion thread is in a thread on our developers list, and the metabug to track it is bug 929685.

16. October 2013

Release of Bugzilla 4.5.1, 4.4.1, 4.2.7, and 4.0.11

by Bugzilla Team

Today we have several new releases for you!

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 4.4.1 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.2.7 is a security update for the 4.2 branch and also includes several bug fixes:

Bugzilla 4.0.11 is a security update for the 4.0 branch and also includes several bug fixes:

Bugzilla 4.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.

12. July 2013

Bugzilla Project Meeting Wednesday, July 17th, at 14:00 UTC

by Dave Miller (justdave)

Much of this post is taken from a message I posted to the developers list a few days ago, so my apologies in advance to anyone reading it again. I’ve expanded on a few things and added the information about the upcoming meeting, so it’s probably worth re-reading.

For those unaware of the context, Frédéric Buclin last week announced that he was stepping down from his Assistant Project Manager position after 9 years.

To Frédéric: Thanks again (and again!) for all your hard work over the years! As stretched as I’ve been for time myself it has been a true godsend to have you picking up my slack the last few years. You will be missed!

To everyone else: For the time being, I’ll be handling approval requests, so if you have something up for approval and it’s not getting attention, I’m the one to pester.

This is sort of the end of an era for the Bugzilla project… Both Frédéric and Max (who left to work at Google a couple years ago and stepped down from his position earlier this year for lack of time) have been with the project for much longer than most people ever stick with a single employer in IT-related jobs (of which an open source project of this magnitude has a lot of similarities). For an open source project, that’s outright amazing, as people tend to come and go a lot in most projects. It’s kind of surprising that I’ve been around longer than them, but I’m kind of a “lifer” in some ways, and in reality I’ve had a good break from the project for the last few years because Max and Frédéric have been mostly taking care of everything while I’ve been busy with other things.

So it’s time to begin a new era. Since I’ve had a good break to clear the monotony I’m going to be trying to get more involved myself again (which I’ve been saying ever since Max left, but I have a lot more incentive now). I’d also like to kickstart a new team to lead the project, and kind of re-organize if you will. We have a number of positions within the project for various functions, which we’ve never really paid attention to as people moved on. So some questions we’ll be asking at our upcoming meeting are:

  • What positions in our existing structure do we have open?
  • Do we still need them all?
  • Are there new positions we have a need for that we should create?
  • Who should fill them?
  • Do the existing holders of positions that we still need and haven’t been vacated want to keep doing them?

We also have some other “reinventing the project” type topics while we’re at it. There’s a number of things we’ve been talking about doing for a long time that we never really moved on, and some of the big elusive dreams (the big UI overhaul!) have actually been making progress as well, lately. When we’re in the middle of big changes like this, I think it’s a good time to review where we are, get everyone on the same page, and tackle some of these things we keep talking about.

We also have a lot of new useful technology at our disposal since the last time we had a project meeting. We’re going to experiment with using Google Hangouts for the meeting this time, and using their feature to stream the Hangout via YouTube for those who want to watch without participating. We’ll also keep our usual meeting IRC channel open so people who don’t have a Google+ account and don’t want to get one can still participate and ask questions via IRC.

The preliminary agenda and participation instructions have been posted at https://wiki.mozilla.org/Bugzilla:Meetings. The meeting will be held on Wednesday, July 17th, at 14:00 UTC. And before anyone complains about the time, this was the best time to avoid inconveniencing the largest number of people. The Bugzilla Project has a global pool of contributors, and we have active contributors in a wide variety of time zones. The time chosen puts the meeting in the middle of the night for the fewest number of people. Those on the west coast in the US will probably have to get up a little early, and those in eastern Australia will be up a little later.

A lot of the emails and comments I’ve gotten since Frédéric’s announcement have been really positive, so I’m encouraged by the number of people who are still committed to keeping Bugzilla vibrant! We’ll see you at the meeting on Wednesday!

22. May 2013

Release of Bugzilla 4.4 and 4.2.6

by Bugzilla Team

Today the Bugzilla Project is extremely proud to announce the release of Bugzilla 4.4!

It has been over a year since we released Bugzilla 4.2 on February 2012, and this new major release comes with several new features and improvements. This release contains major improvements to WebServices, which were our main target in this release, a rewritten tagging system, a real MIME type auto-detection for attachments, improved support for Oracle, performance improvements and lots of other enhancements.

We hope that you enjoy and appreciate the results of this past year of hard work by our entirely-volunteer community.

Bugzilla 4.2.6 is a bug fix update for the 4.2 branch:

EOL for 3.6.x

Please note that the release of Bugzilla 4.4 also marks End Of Life for the Bugzilla 3.6 series, meaning that there will be no further updates for the 3.6.x series, even if there are serious security issues found in that series. We recommend that all installations running the 3.6 series upgrade as soon as possible to 4.4.

19. February 2013

Release of Bugzilla 4.4rc2, 4.2.5, 4.0.10, and 3.6.13

by Bugzilla Team

Today we have several new releases for you!

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 4.4rc2 is our second Release Candidate for Bugzilla 4.4. 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 4.4 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.

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

Bugzilla 4.0.10 is a security update for the 4.0 branch:

Bugzilla 3.6.13 is a security update for the 3.6 branch:

06. December 2012

Upgrading your Bugzilla? Don't forget to Sanity Check first.

by Bugzilla Team

When planning on upgrading your Bugzilla to a newer version, it’s always a good idea to read the release notes in case of special instructions that need to be done to handle certain situations in upgrades.  Our checksetup.pl script has gotten pretty good at handling a lot of situations automatically for you these days, but nothing is ever perfect.

One instruction in the upgrade procedure for every release that often gets overlooked is to run the Sanity Check function from the Admin page on your Bugzilla site before upgrading.  It checks the integrity of the data in your database and will alert you to a number of possible problems with your data.  Sometimes bugs in Bugzilla or even people manually messing with the database will cause something to not be how Bugzilla expects it, and every so often one of these problems can cause issues for an upgrade.  Fixing any problems reported by Sanity Check before each upgrade can save you a lot of headaches.

In a recent example: newer versions of Bugzilla allow you to edit the available statuses and resolutions on bugs.  Older versions didn’t.  One of the steps performed by the upgrade script is to examine your database, take whatever current statuses you’ve been using (even if you hacked your Bugzilla to allow different ones before we actually let you customize them), and convert them to the way the new customizable ones are stored.  The new custom status system has a flag to distinguish between statuses that are allowed to have resolutions and those that aren’t.  When upgrading, it decides whether to set that flag on a status or not by looking in your database to see if there are any bugs with that status that have resolutions on them.  If it finds any, the status is set up to use them.

A long time ago there was Bug 107229 which caused duplicate bugs to get the wrong status if you midaired while marking it a duplicate.  This caused bugs to exist in an “ASSIGNED DUPLICATE” state that should have been “RESOLVED DUPLICATE”.  A side effect is if it was left that way, when you later upgraded to a version of Bugzilla that included the custom statuses, your ASSIGNED status became a “closed” type instead of an “open” one, and would require a resolution.  Sanity Check most likely would have caught this, as it checks for things like resolutions where there shouldn’t be any. :)

13. November 2012

Release of Bugzilla 4.4rc1, 4.2.4, 4.0.9, and 3.6.12

by Bugzilla Team

Today we have several new releases for you!

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 4.4rc1 is our first Release Candidate for Bugzilla 4.4. 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 4.4 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.

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

Bugzilla 4.0.9 is a security update for the 4.0 branch:

Bugzilla 3.6.12 is a security update for the 3.6 branch:

30. August 2012

Release of Bugzilla 4.3.3, 4.2.3, 4.0.8, and 3.6.11

by Bugzilla Team

Today we have several new releases for you!

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 4.2.3 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.0.8 is a security update for the 4.0 branch:

Bugzilla 3.6.11 is a security update for the 3.6 branch:

Bugzilla 4.3.3 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.

26. July 2012

Release of Bugzilla 4.3.2, 4.2.2, 4.0.7, and 3.6.10

by Bugzilla Team

Today we have several new releases for you!

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 4.2.2 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.0.7 is a security update for the 4.0 branch:

Bugzilla 3.6.10 is a security update for the 3.6 branch:

Bugzilla 4.3.2 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.