Watching the floor drop out under our feet

Well, this was unexpected. Multiple places across Bugzilla with 4.0-ready patches are now being denied to land on mozilla-2.0, and the reason appears to be that there will not be a Firefox 4.0.2. Instead, Mozilla is dropping Firefox 4 after 4.0.1 and going straight to Firefox 5. In fact, Firefox 3.6 will be supported longer than 4.0 will!

(I should clarify that while a dummy 4.0.2 release is being [lightly] considered as a migration strategy for the end of Firefox 3.5, it would have no new content and would explicitly be just a version bump. We aren't going to do that.)

That was the bad news, now for the good news. My request to receive Mozilla security group privileges was accepted, and I am now able to view security issues as they are submitted and as they develop. Using this new access, I've been able to identify some security and stability fixes that apply to 4.0.1 (and some to 3.6, but there will be a 3.6.18 for those of you who are still unsure about jumping to TenFourFox) and that can be accepted by us safely, to keep us at security parity while I ponder what to do with Firefox 5 as it enters the beta channel.

Because this essentially forces us into unsupported mode early, we're going to adopt a new strategy to reduce branch-to-branch-jump work and yet crosspatch future patches to our codebase in a reasonably straightforward manner. Once we lose source parity, this will change, but as long as we maintain source parity and are built from a Mozilla release we will maintain this new strategy (builders take note):

- Each branch will have a base set of patches specific to that branch. In the case of Firefox 4.0.1, it is the changeset that is already available and that you can download now. These sets are the "base" and are the unique TenFourFox portions the browser is built upon. They should be unique to that branch and should not carry future work unless absolutely necessary, i.e., no changesets that would be part of a future Firefox branch. The reason for this is that the base will be carried forward to the next release of Firefox and modified as needed, so we don't want changesets that would already be in that release (most importantly stability and security fixes we backported from the future branch). The base may be added to if we find TenFourFox-specific bugs that we need to repair in point releases.

- On top of that will come specific future changesets that we are backporting for stability or security. There are ten of these I am reviewing for probable inclusion in TenFourFox 4.0.2, and about six others of low severity that we may or may not take. None of these are highly critical, but we should fix them. These changests are already in Firefox 5; we do not want to carry them forward in the base. These changesets will be maintained separately and will not be reapplied to "mozilla-5.0" or whatever they're going to call it because they don't need to be. The version and milestone should be maintained here too because we definitely don't want to have to merge that in base.

So, for 4.0.2, new base changes will be the compiler string modifications and UPDATE: the compiler changes make the app really unstable, so we're not shipping them for 4.0.2 the pref for enabling or disabling smooth scroll with plugins. We will then establish a maintenance changeset with the new version and milestone numbers and the security/stability patches, which I'll document in the release notes. Builders need to apply both the base and the maintenance changesets to generate a complete version. When Firefox 5 comes out of beta, then we'll immediately clone that repo and apply the Firefox 4 base to it, making any additional changes that we will need and thus creating a new base for that release branch (assuming it works, of course -- see the previous entry for why this is probable but not guaranteed). Assuming a TenFourFox 5, while we wait for Firefox 6, we will watch for security updates and backport to 5.0.1 as necessary.

I have not yet decided if there will be a 4.0.3. If there are no major issues by the time TenFourFox 5 dawns and it seems to work, then we will simply release. If there are some issues identified of sufficient severity that do still affect us, I will issue a 4.0.3 for those who can't give up plugins just yet so that it can buy them some time.

Like every version of TenFourFox, you will never be upgraded automatically to a new version unless you download and install it yourself. I don't like this personally and I don't like forcing it on people, and we don't have the infrastructure for it anyway. If we liked forced upgrades, we wouldn't be using Power Macs. ;)

The current plan is to select and land patches this week and chug out builds over the weekend for you, the loyal beta audience. 4.0.2pre should be available on Monday, and if there are no major issues 4.0.2 final will come out on June 1st. As always, comments and questions solicited.