Mozilla Thunderbird: Development Specifics
This document discusses specifics for Thunderbird development in relation to Firefox's development model and development specifics.
Please note this is a draft document and subject to change.
Discussion should take place on tb-planning.
Schedule Driven Process
Thunderbird development has moved to a schedule-driven process, where releases take place at regular intervals. That means that releases happen regardless of whether a given feature is ready, and releases are not delayed to wait for a feature to stabilize. The goal of the process is to provide regular improvements to users without disrupting longer term work.
In switching to the schedule-driven process, we are following Firefox's schedule. Please read the Firefox Development Process overview for specific information about the release cycles that will be happening.
There will be four update channels equivalent to the Firefox channels:
- Daily, equivalent to Firefox's Nightly.
- Earlybird, equivalent to Firefox's Aurora.
The channels have progressively more stability and more users, and also different update rates:
|Channel||Users||Anticapted Update Rate||Branded||Notes|
|Daily||600||600||Mozilla developers and power users willing to risk instability to see and test the latest fixes||nightly||Daily||Our current nightly audience|
|Earlybird||500||30,000||Power users willing risk instability to see and test the latest fixes. There are higher stability expectations versus nightly||nightly||Earlybird||A new channel which we can promote to our users.|
|Beta||20,000||100,000||Current beta channel users||weekly (dependent on issues found)||Thunderbird||Our current beta channel audience|
|Release||7+ million||Many more!||Normal Thunderbird users||6-12 weeks||Thunderbird||This is the current release channel. When a build is offered on this channel it means a new version of Thunderbird has been officially released.|
Schedule of Milestones
In general, each stage of the process (and activity pertaining to a particular version) lasts for 6 weeks. At the end of each 6 week cycle, the work is merged across to the next branch, with comm-central starting work for the next release on the chain.
Please do note that chemspills / rapid response updates are not reflected in these schedules and will be dealt with on an as-needed basis.
This proposal makes security updates occur along with Thunderbird releases, meaning we'll no longer be maintaining old branches. The previous Thunderbird release will be End of Life when the next release comes out.
We recognise this will provide challenges for Enterprise situations, we are discussing ideas and options on the Enterprise User Working Group mailing list.
There are four main repositories that echo the Firefox repository structure.
These repositories will include gecko from the mozilla-* repository of the equivalent name. Hence when a patch lands in the equivalent mozilla-* repository, it will immediately be available for Thunderbird builds.
Just like the current repository
Stabilize work done on comm-central for release
Fix any issues that come up during the beta validation of the comm-aurora stabilization
Repository for code to generate officially released Thunderbird binaries
Development vs Release
The repositories can generally be grouped into two overall processes: development and release. comm-central is part of the development process. The downstream repositories are part of the release process.
This document mainly covers the release process. Details about project pages, feature tracking, and bug management are out of scope for this proposal and will be discussed soon.
What Happens Where?
- General development
- Project repository merges
- en-US changes
- Some localization
- Preffing off and backing out fixes/features which the central channel exposes as problematic with a wider audience.
- Remaining localizations
- Landing spot fixes to get the product in a shipping state
- Preffing off and backing out fixes/features which were deemed ready but testing determined they in fact were not
- en-US changes are not allowed in comm-aurora.
- Interfaces should generally remain stable
- Fixes for newly-found issues which would prevent a final release
- In extreme cases backouts / pref offs
- APIs are stable so that add-ons can be prepared and updated
- String changes are not allowed for en-US, localisations may finialize strings before the final beta.
- Nothing is landed. The repo is just for reference and available for cloning if a rapid response release is needed
Because updates are (intended) to be silent and automatic we can generally assume a user on a given channel is on the latest available build. This assumption simplifies things greatly.
Unless major issues are discovered with the scheme, this is how builds in the assorted repositories will identify themselves:
The following considerations are reflected in the versioning scheme:
- No "pre" as it is no longer necessary - the nightly and earlybird channels replace the alphas, and the beta channel does not have nightly updates
- Ease of version comparisons between channels and releases
- Amount of changes required to existing tools and systems
- Ability to identify which channel a user is on from the build
- Beta and release versions should identify as the same version to make sure beta testing is valid and no last-minute issues are found due to a version change
Thunderbird will be based on the equivalent version of Gecko to Thunderbird's version number.
Please note that binary extensions are expected to need to be recompiled for each release.
Localization work will be split into similar repositories:
There will be some locales that track comm-central localizing alongside en-US development. Other locales can track comm-central if they would like to as well but they won't be asked to explicitly.
comm-central will be string frozen for en-US at the comm-central → comm-aurora merge point. No en-US string changes will be allowed on comm-aurora. The comm-central → comm-aurora merge date will happen on schedule so the string freeze should not come as a surprise.
For locales that don't track comm-central, their work is done in l10n/mozilla-aurora, which tracks comm-aurora. This means most locales have 6 weeks to complete their localizations.
TBD (but similar to FF)
No work is deferred from upstream repos to downstream repos. If your feature / change isn't finished on comm-central, comm-aurora is not the place to fix it up. If there is outstanding work on comm-aurora do not plan to fix it in comm-beta. The clone / pull dates are published far in advance so there should be ample time to plan. If it's not ready it should be backed out or preffed off. There will be another release in 6-12 weeks for the fix to try to make it in again.
Merging between repos will happen on schedule. Again, consistency is key. Groups will be able to plan and won't need to be intimately involved with the release process to know where fixes are and where fixes should be landed. Additionally, if we don't merge on time then mozilla-* merges will most likely break out repositories.
The merge between release repos should be automatic
When the time comes to merge upstream release repositories with downstream repositories we are essentially replacing the downstream repository with a copy of the upstream. Because the merge/clone should never fail and it happens on a set schedule it will likely be automated.
Please note in the section above there is still discussion on what can be automated and the proper version control mechanics.
Preffing off / backing out happens after the clone
When cloning from comm-central to comm-aurora the backouts and pref offs take place on the comm-aurora repo. This allows comm-central to use the complete allotted time for development and utilizes comm-aurora's time for convergence.
Add-ons are an intergral part of the Thunderbird ecosystem. For each release, add-on authors will have 12 weeks to update their extensions. We will be working with add-on authors to help them in their task. To do this we are intending to:
- Automatically increase extension compatibility whenever it is apparent that a new release shouldn't affect an extension's functionality
- Notify the author(s) of the extension that the increase was or wasn't successful
- Provide documentation with each release on what APIs have changed
- Work towards improving APIs to help extension authors more easily add functionality
- Have an add-on development co-ordinator to improve communication to add-on authors and help resolve any questions