Mozilla Messaging has published a proposed schedule for Thunderbird 3.1, the next release of the popular e-mail client. The organization is refining its development process and could potentially shift towards shorter release cycles and a more incremental approach to development.
Mozilla Messaging, the Mozilla subsidiary behind the Thunderbird project, has revealed a preliminary roadmap proposal for the next major version of the open source e-mail client. The developers could potentially adopt a more incremental development model with shorter release cycles.
According to a new proposed schedule that has been published in the Mozilla wiki, Thunderbird 3.1 is tentatively planned for release in April. The new version will include an updated Gecko engine and some features that weren't quite ready for the 3.0 release. The roadmap states that large and disruptive changes will be avoided during this development cycle.
"Developers are encouraged to take this opportunity to land changes that respond to support issues, sand off rough edges, and land small bits of work that we had hoped to see in the 3.0 cycle, but didn't make it," the roadmap says.
Mozilla Messaging CTO Dan Mosedale has published some notes that elaborate on the changes that the organization is contemplating for its development model. The notes indicate that the Thunderbird team hopes to align its development cycle more closely with that of the Firefox Web browser. This will allow Thunderbird to better leverage the constant stream of improvements that the Firefox development community is making to Gecko and other components that are shared between Firefox and Thunderbird.
The proposal is to deliver a new Thunderbird release every four to six months and have a prerelease build available for testers every four weeks. The proposal suggests that this schedule could be adopted loosely with exceptions made as needed. As we have previously discussed in articles about release management, time-based development cycles work very well for some projects but pose a number of challenges and can sometimes make it difficult to integrate major changes. Mosedale's notes acknowledge this challenge and also point out that the new development model could introduce a higher QA burden.
In addition to plans for Firefox 3.1, the developers are also starting to look beyond the next release at plans for the future. One of the long-term strategies that is under discussion is the possibility of more heavily using add-ons as a means of prototyping user interface changes. Like Firefox, Thunderbird has very rich support for extensibility, giving third-party developers a significant amount of control over the program's behavior and presentation. Taking advantage of these strengths during the development process makes a whole lot of sense.
This approach will be more conducive to rapid iteration and it will give the developers more freedom and flexibility as they experiment with changes. It will also help keep prereleases more stable and consistent because they won't have to directly include half-baked changes that are still under heavy development.
"We did some UI iteration in extensions in Thunderbird 3, with varying degrees of pain-upon-landing. The big win, it felt like, was the ability to get UI to a workable and understood state before imposing it on everyone using nightly builds," say Mosedale's notes. "We'd like to explore this methodology more going forward, but we'll need to nail down more details about our process and what sorts of experiments with it that we'd like to do."
He also wrote about the possibility of changing the way that release roadmaps are developed. "Rather than having a single big roadmap that then ends up having lots of things cut from it at the end, [David Ascher] has suggested that we instead have individual roadmaps for different feature and code areas, particularly those where we can avoid a lot of cross-dependencies," he wrote. "We can then pick appropriate pieces of work from various different road maps and target them at a given release."
This sounds similar in some ways to the "blueprints" that Canonical uses to establish its feature plans for Ubuntu releases.
Many readers have inquired about the status of the Lightning project, a sophisticated Thunderbird add-on that brings calendaring support and other similar capabilities to the mail client. The developers Link Removed due to 404 Error this week the availability of the Lightning 1.0 beta 1 release candidate which is compatible with Thunderbird 3. Lightning is still largely experimental but shows a lot of promise.
Conclusion
It's important to note that the wiki documents where all of these ideas appear are clearly marked with the "DRAFT" label, indicating that they are still only preliminary proposals under discussion and not yet concrete plans. These ideas could evolve considerably between now and when they are put into practice.
Because it's all so amorphous, we don't usually delve much into this kind of very early-stage planning when we write about Mozilla software. We think it's really enlightening in this case because it provides a lot of insight into how Mozilla Messaging is thinking about its development practices. The organization is a relatively new (Thunderbird 3 was the first major release since Mozilla Messaging was founded in 2008) and is still defining itself in many key ways.
The impressive Thunderbird 3.0 release validated the technical vision of Mozilla Messaging and set a strong precedent for innovation. During the 3.1 cycle, it seems like the organization is aiming to use what it learned from building 3.0 to refine the development workflow and create processes that will be conducive to pushing the project forward in the direction that it started moving with 3.0.
Mozilla Messaging, the Mozilla subsidiary behind the Thunderbird project, has revealed a preliminary roadmap proposal for the next major version of the open source e-mail client. The developers could potentially adopt a more incremental development model with shorter release cycles.
According to a new proposed schedule that has been published in the Mozilla wiki, Thunderbird 3.1 is tentatively planned for release in April. The new version will include an updated Gecko engine and some features that weren't quite ready for the 3.0 release. The roadmap states that large and disruptive changes will be avoided during this development cycle.
"Developers are encouraged to take this opportunity to land changes that respond to support issues, sand off rough edges, and land small bits of work that we had hoped to see in the 3.0 cycle, but didn't make it," the roadmap says.
Mozilla Messaging CTO Dan Mosedale has published some notes that elaborate on the changes that the organization is contemplating for its development model. The notes indicate that the Thunderbird team hopes to align its development cycle more closely with that of the Firefox Web browser. This will allow Thunderbird to better leverage the constant stream of improvements that the Firefox development community is making to Gecko and other components that are shared between Firefox and Thunderbird.
The proposal is to deliver a new Thunderbird release every four to six months and have a prerelease build available for testers every four weeks. The proposal suggests that this schedule could be adopted loosely with exceptions made as needed. As we have previously discussed in articles about release management, time-based development cycles work very well for some projects but pose a number of challenges and can sometimes make it difficult to integrate major changes. Mosedale's notes acknowledge this challenge and also point out that the new development model could introduce a higher QA burden.
In addition to plans for Firefox 3.1, the developers are also starting to look beyond the next release at plans for the future. One of the long-term strategies that is under discussion is the possibility of more heavily using add-ons as a means of prototyping user interface changes. Like Firefox, Thunderbird has very rich support for extensibility, giving third-party developers a significant amount of control over the program's behavior and presentation. Taking advantage of these strengths during the development process makes a whole lot of sense.
This approach will be more conducive to rapid iteration and it will give the developers more freedom and flexibility as they experiment with changes. It will also help keep prereleases more stable and consistent because they won't have to directly include half-baked changes that are still under heavy development.
"We did some UI iteration in extensions in Thunderbird 3, with varying degrees of pain-upon-landing. The big win, it felt like, was the ability to get UI to a workable and understood state before imposing it on everyone using nightly builds," say Mosedale's notes. "We'd like to explore this methodology more going forward, but we'll need to nail down more details about our process and what sorts of experiments with it that we'd like to do."
He also wrote about the possibility of changing the way that release roadmaps are developed. "Rather than having a single big roadmap that then ends up having lots of things cut from it at the end, [David Ascher] has suggested that we instead have individual roadmaps for different feature and code areas, particularly those where we can avoid a lot of cross-dependencies," he wrote. "We can then pick appropriate pieces of work from various different road maps and target them at a given release."
This sounds similar in some ways to the "blueprints" that Canonical uses to establish its feature plans for Ubuntu releases.
Many readers have inquired about the status of the Lightning project, a sophisticated Thunderbird add-on that brings calendaring support and other similar capabilities to the mail client. The developers Link Removed due to 404 Error this week the availability of the Lightning 1.0 beta 1 release candidate which is compatible with Thunderbird 3. Lightning is still largely experimental but shows a lot of promise.
Conclusion
It's important to note that the wiki documents where all of these ideas appear are clearly marked with the "DRAFT" label, indicating that they are still only preliminary proposals under discussion and not yet concrete plans. These ideas could evolve considerably between now and when they are put into practice.
Because it's all so amorphous, we don't usually delve much into this kind of very early-stage planning when we write about Mozilla software. We think it's really enlightening in this case because it provides a lot of insight into how Mozilla Messaging is thinking about its development practices. The organization is a relatively new (Thunderbird 3 was the first major release since Mozilla Messaging was founded in 2008) and is still defining itself in many key ways.
The impressive Thunderbird 3.0 release validated the technical vision of Mozilla Messaging and set a strong precedent for innovation. During the 3.1 cycle, it seems like the organization is aiming to use what it learned from building 3.0 to refine the development workflow and create processes that will be conducive to pushing the project forward in the direction that it started moving with 3.0.
