Mac OS X 10.5 Support Plans (Updated)

[Josh Aas]

[This is an updated copy of my last proposal. The major change is that this targets Firefox 17 instead of Firefox 16. Other data has been updated and made more accurate as well.]

I'd like to propose that we remove support for Mac OS X 10.5 in Firefox 17, which should ship on or near November 13, 2012. To be clear: this is not a decision that has been made, I’m proposing it here in order to get feedback.

First, some facts:

=================================
Mac OS X Release Dates) 10.5 was released in October of 2007, 10.6 was released in June of 2009, 10.7 was released in July of 2011. Mac OS X 10.8 will be released during the summer of 2012.

Mac OS X User Breakdown) Mac OS X users make up 4.6% of Firefox 13 (current stable) users as of June 21, 2012. Of those Mac OS X users, 17% are on Mac OS X 10.5, 35% are on Mac OS X 10.6, and 48% are on Mac OS X 10.7.

Trends) Mac OS X 10.5 users have been declining by 1% per month (as a share of our total Mac OS X users). This, combined with the impact of the release of Mac OS X 10.8, means that Mac OS X 10.5 users will likely make up around 10% of Mac OS X users when Firefox 17 ships.
=================================

Apple releases new versions of its operating systems relatively quickly and each new version contains significant changes that we must adapt to. This requires resources, and with limited resources this sometimes means we have to make tough decisions about where to invest.

We still have significant integration work to do for Mac OS X 10.7 and we’re getting more for Mac OS X 10.8. Currently we have to go back and make sure we didn’t cause problems on Mac OS X 10.5 every time we do integration work for newer OS versions. In addition to the core Mac OS X platform layer (Cocoa widgets), subsystems such as plugins and graphics are affected by the Mac OS X 10.5 requirement.

Build, release, and testing infrastructure resources are also consumed by the Mac OS X 10.5 requirement.

There are already some significant ways in which Firefox on Mac OS X 10.5 has fallen behind Firefox on newer versions of Mac OS X. Accelerated compositing, WebGL, and out-of-process plugins are not available on Mac OS X 10.5.

Google has already announced their plans to drop Chrome’s support for Mac OS X 10.5 in Chrome 22 [1]. Chrome 22 will likely be released on or around October 19, 2012.

Finally, Apple has already stopped supporting Mac OS X 10.5, and Adobe will likely stop shipping security updates for Flash on Mac OS X 10.5 soon. While Apple does not officially drop support for older OS versions, they have stopped shipping security updates and updating applications like Safari.

[1] https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/3nUlhuHbf0Q

[Simon Kornblith]

On Jun 21, 6:37 am, Josh Aas <josh...@gmail.com> wrote:
> Finally, Apple has already stopped supporting Mac OS X 10.5, and Adobe will likely stop shipping security updates for Flash on Mac OS X 10.5 soon. While Apple does not officially drop support for older OS versions, they have stopped shipping security updates and updating applications like Safari.

It seems like Apple's support for 10.5 is a complicated situation. The
last security update for 10.5 came out a month ago (http://
support.apple.com/kb/HT5283). However, looking at the list of security
updates (http://support.apple.com/kb/HT1222), 10.5 isn't getting
updates at the same rate as 10.6+. Notably, I don't think Apple ever
patched Java on Leopard for CVE-2012-0507.

Simon

[Asa Dotzler]

On 6/21/2012 3:37 AM, Josh Aas wrote:
> [This is an updated copy of my last proposal. The major change is
> that this targets Firefox 17 instead of Firefox 16. Other data has
> been updated and made more accurate as well.]
>
> I'd like to propose that we remove support for Mac OS X 10.5 in
> Firefox 17, which should ship on or near November 13, 2012. To be
> clear: this is not a decision that has been made, I’m proposing it
> here in order to get feedback.

Josh, thank you for the updated information and proposal. Though it's
always a difficult decision to leave some users behind, I think your
timline and reasoning is solid and I support this plan.

--
Asa Dotzler
for the Firefox Product team

[Armen Zambrano G.]

FTR this would help with release engineering infrastructure and the time
that developers have to wait for test results in platforms like Windows
XP and Windows 7.
We would rbe e-purposing the Leopard revision 3 minis as XP and Win7
machines.

We have other initiatives to move Win7 and WinXP away from using rev3
minis but that is aimed at the end of the year due to lack of human
resources and b2g taking resources in Q3.

cheers,
Armen

[Chris Peterson]

On 6/21/12 3:37 AM, Josh Aas wrote:
> I'd like to propose that we remove support for Mac OS X 10.5 in Firefox 17, which should ship on or near November 13, 2012.

AFAIK, Firefox 17 is the next ESR. Is you choice of that release because
you specifically want to avoid supporting Mac OS X 10.5 for the duration
of the next ESR?


chris p.

[Alex Keybl]

I don't believe this was a driver for the proposed desupport timeline. At the same time, it shouldn't be a reason to delay the desupport either. The ESR is meant to serve organizational deployments, and therefore very old versions of operating systems won't be a consideration. Mac OS X 10.5 isn't used by organizations because it is for the most part insecure at this point.

-Alex

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Zack Weinberg]

On 2012-06-21 11:32 AM, Alex Keybl wrote:
> I don't believe this was a driver for the proposed desupport
> timeline. At the same time, it shouldn't be a reason to delay the
> desupport either. The ESR is meant to serve organizational
> deployments, and therefore very old versions of operating systems
> won't be a consideration. Mac OS X 10.5 isn't used by organizations
> because it is for the most part insecure at this point.

This may all be true, but if we can afford to postpone the desupport
until immediately after the ESR, that would go a long way toward
reducing the extent to which we are leaving users who can't upgrade in
the lurch.

(In general, I think "one release after an ESR" is the least bad time to
drop support for old platforms, and "in the baseline for an ESR" is the
*worst* time to do so.)

zw

[Mike Hommey]

On Thu, Jun 21, 2012 at 03:37:02AM -0700, Josh Aas wrote:
> [This is an updated copy of my last proposal. The major change is that
> this targets Firefox 17 instead of Firefox 16. Other data has been
> updated and made more accurate as well.]
>
> I'd like to propose that we remove support for Mac OS X 10.5 in
> Firefox 17, which should ship on or near November 13, 2012. To be
> clear: this is not a decision that has been made, I’m proposing it
> here in order to get feedback.

It would be useful to add information as to why not support OSX 10.5
until Firefox 18, considering 17 is going to be ESR.

Mike

[Asa Dotzler]

On 6/21/2012 11:48 AM, Zack Weinberg wrote:
> On 2012-06-21 11:32 AM, Alex Keybl wrote:
>> I don't believe this was a driver for the proposed desupport
>> timeline. At the same time, it shouldn't be a reason to delay the
>> desupport either. The ESR is meant to serve organizational
>> deployments, and therefore very old versions of operating systems
>> won't be a consideration. Mac OS X 10.5 isn't used by organizations
>> because it is for the most part insecure at this point.
>
> This may all be true, but if we can afford to postpone the desupport
> until immediately after the ESR, that would go a long way toward
> reducing the extent to which we are leaving users who can't upgrade in
> the lurch.

That presumes we'd move those users off of Firefox's normal train and
onto ESR, something we will not do.

- A

[Neil]

They can hardly stay on Firefox's normal train if you're dropping
support for them.

--
Warning: May contain traces of nuts.

[Zack Weinberg]

Or that they will move themselves.

> something we will not do.

Rejecting the possibility out of hand seems like a bad decision to me.

zw

[Alex Keybl]

The reasoning behind keeping the ESR for organizational deployments only has been noted many times, and was even on a previous iteration of this thread.

https://groups.google.com/forum/#!msg/mozilla.dev.planning/70QOVDgbNEo/8hXguxPouYgJ

-Alex

[Ted Mielczarek]

On Thu, Jun 21, 2012 at 2:32 PM, Alex Keybl <ake...@mozilla.com> wrote:
> The ESR is meant to serve organizational deployments, and therefore very old versions of operating systems won't be a consideration.

Can you really say this with a straight face? When we dropped Windows
2000 support we got a lot of flack from organizations that were still
using it despite it being hopelessly out of date and unsupported.
Large corporations and other "enterprise" organizations are notorious
for sticking with outdated software well past its prime. I think I'd
want to see some data to back up this assertion.

(Not that I particularly care one way or the other, this particular
assertion just doesn't make sense to me.)

-Ted

[Alex Keybl]

From https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal
> The release schedule doesn't allow sufficient time for the organizations and their vendors to certify new releases of the products
> the associated end-of-life policy exposes them to considerable security risk if they remain on a non-current version past Firefox 3.6.
Can you explain why we'd make security our #1 priority for the ESR, but wouldn't expect the same from organizations deploying the ESR?

-Alex

[Alex Keybl]

I'll add that if this desupport is targeted for FF17, it'll give us ~5 months to communicate the desupport of an insecure OS externally to enterprises. That seems ample to me.

-Alex

[Cameron Kaiser]

This was why I asked in Josh's previous thread to hold dropping 10.5
until after 17. I would not object to 18. I would be sad to see 10.5
support go, but I understand the rationale.

That said, TenFourFox is now holding a lot of legacy users, and a
number of people dissatisfied with its performance are looking at
porting it to Intel 10.4, despite our support stance of telling these
people to update to 10.6. I fully expect that we will also inherit
orphaned 10.5 users after such a change.

We use the ESR as our stable release so that we can deal with churn on
-release and -beta. We were able to weather the change from 10.4 to
10.5, but I expect that there will be leveraging of OS 10.6+ features
that cannot be coded around for 10.4 which may well sink our ability
to continue with the port. If the change occurs after ESR, we migrate
our users to a new stable ESR based on 17 and at least that group of
users will continue to receive updates -- supported by us, not
Mozilla: we direct people away from SUMO to our own support site and
handle our own bug reports -- for the life of 17ESR and likely
afterwards, even if we are unable to make the jump to 18.

So I'm respectfully asking to hold the change over until 17 ESR has
branched. It would extend the life of us and other cottage 10.4/10.5
ports (SeaMonkeyPPC, AuroraFox, Tenfourbird, etc.), and would delay
this change by only one more release.

Cameron Kaiser

[Zack Weinberg]

On 2012-06-21 3:55 PM, Alex Keybl wrote:
> The reasoning behind keeping the ESR for organizational deployments
> only has been noted many times, and was even on a previous iteration
> of this thread.
>
> https://groups.google.com/forum/#!msg/mozilla.dev.planning/70QOVDgbNEo/8hXguxPouYgJ

I endorse Jonathan Kew's rebuttal of that reasoning:

akeybl> The ESR branch is meant for organizations and institutions with
akeybl> their own internal support structure in order to enable them to
akeybl> qualify and roll out new releases on a timeline that they're
akeybl> comfortable with. Sending our other users to a release which
akeybl> doesn't have the full support and attention that our newer
akeybl> releases have likely isn't the right call.

jkew> If we ship an ESR in early 2012 (for example), my understanding is
jkew> that we'll "support" that with critical security updates for at
jkew> least a year or so. OTOH, a 10.5 user on the non-ESR track would
jkew> receive _no_ updates even for critical security issues as soon
jkew> as FF13 ships at the beginning of June (under Josh's proposal).
jkew>
jkew> Surely it's better to suggest 10.5 users who can't update their OS
jkew> should move to Firefox ESR than to leave them on a non-ESR release
jkew> for which they can no longer receive _any_ updates, because the
jkew> only supported update we offer for it won't run on their platform.
jkew>
jkew> They'll still face the problem once the ESR is EOL'd, of course,
jkew> but at least that would buy them some additional time.

Furthermore we have Cameron Kaiser offering to provide user support via
the TenFourFox organization in this case, so I don't think we have to
worry about added support load on Mozilla (but even if we did, I would
think it would be worth it).

zw

[Cameron Kaiser]

On Jun 25, 11:34 am, Zack Weinberg <za...@panix.com> wrote:
> Furthermore we have Cameron Kaiser offering to provide user support via
> the TenFourFox organization in this case, so I don't think we have to
> worry about added support load on Mozilla (but even if we did, I would
> think it would be worth it).

It's not just an offer -- we already do. http://tenfourfox.tenderapp.com/
We use that as a triage stage and then move actual work items to the
Google Code project.

The support link within 10.4Fx also doesn't go to SUMO anymore; it
goes to us. I don't think it's reasonable to burden Mozilla support
with 10.4 or PPC specific issues, especially since in some cases it
may well be bugs we introduced in the port. If it's something that we
believe is Mozilla-general, then we'll uplift it to Bugzilla after it
has been triaged. The whole idea is to impact Mozilla resources as
little as possible with our use of the ESR as a stabilizer.

We're already planning "Judgment Day" for 18 to use it as a major
reworking of the port. Besides spinning off widget/cocoa/ and themes/
pinstripe/ into Tiger-specific directories to avoid churn as 10.5
workarounds are replaced, we will also start the PPC IonMonkey port,
and start using gcc 4.6 for building. Having 17ESR as a stable branch
for users is critical to getting this work done, because it buys us
time to maintain viability (we would continue to build TenFourFox-
stable off 17ESR while working on -unstable for 18+).

I appreciate the consideration.
Cameron Kaiser

[Asa Dotzler]

On 6/25/2012 11:34 AM, Zack Weinberg wrote:
> On 2012-06-21 3:55 PM, Alex Keybl wrote:
>> The reasoning behind keeping the ESR for organizational deployments
>> only has been noted many times, and was even on a previous iteration
>> of this thread.
>>
>> https://groups.google.com/forum/#!msg/mozilla.dev.planning/70QOVDgbNEo/8hXguxPouYgJ
>>
>
> I endorse Jonathan Kew's rebuttal of that reasoning

The clear, specific, and very limited focus of ESR is a fundamental
piece of why ESR was allowed to go forward. Revisiting this decision
about its limited scope means revisiting whether or not we do an ESR at all.

I don't think anyone wants to go there.

- A

[Justin Dolske]

On 6/21/12 3:55 PM, Alex Keybl wrote:
> The reasoning behind keeping the ESR for organizational deployments only has been noted many times, and was even on a previous iteration of this thread.
>
> https://groups.google.com/forum/#!msg/mozilla.dev.planning/70QOVDgbNEo/8hXguxPouYgJ

Additionally, while it might be tempting to allow users a few more
months of support via ESR, it very much has costs:

* Build infrastructure would need to continue to support the ability
to build, release, and update on that platform
* Build/test/talos machines dedicated to that platform could not be
freed up (updated) to lessen the load elsewhere
* Developers would need to retain the ability to build and test on
that platform
* QA would need to retain the ability to test on that platform (at
least, I think we do some ESR QA?)
* We'd need to do work (and testing) to actually migrate users to ESR.

One might argue that it's better to drop support immediately _before_ an
ESR!

Justin

[Boris Zbarsky]

On 6/25/12 9:37 PM, Justin Dolske wrote:
> * Developers would need to retain the ability to build and test on that
> platform

Case in point: a test for new bindings I just checked in today failed on
10.5, because there is no WebGL support there and the test was using the
WebGL context to exercise the binding code...

-Boris

[Cameron Kaiser]

Would an acceptable compromise be to set the minimum version of
the .plist to 10.6.8 in 17, and delay the removal of the actual 10.5
code until 18? Then 10.6+ features can land in 17, and would not
require testing against 10.5, but the existing 10.5 code would still
move into the ESR for the benefit of those who (like us) would still
turn it back on. It would save us an expensive and possibly error-
prone merge right before what would have ordinarily been our stable
branch, since most of the code we rely on is still present, but would
hopefully avoid Boris' situation because actual support is gone (and
we would just eat those 10.6+ APIs or back them out if needed).

Either way, I would very much appreciate being cc'ed on bugs removing
10.5 code (spectre et armory dawt com).

Cameron Kaiser

[Gervase Markham]

On 26/06/12 03:37, Justin Dolske wrote:
> Additionally, while it might be tempting to allow users a few more
> months of support via ESR, it very much has costs:

Can we get the best of both worlds, by dropping Mozilla's official
support before the ESR (so we don't have to support it in our ESR, have
tinderboxen, do testing etc.) but not actually making any code changes
which break stuff until after ESR (so TenFourFox can take the ESR and
build on it safely)?

Gerv

[Justin Dolske]

On 6/26/12 6:45 AM, Cameron Kaiser wrote:
> Would an acceptable compromise be to set the minimum version of
> the .plist to 10.6.8 in 17, and delay the removal of the actual 10.5
> code until 18? Then 10.6+ features can land in 17, and would not
> require testing against 10.5, but the existing 10.5 code would still
> move into the ESR for the benefit of those who (like us) would still
> turn it back on.

This seems reasonable enough to me. Although I'm not the one touching
that code. :-)

Justin

[Alex Keybl]

I'm mostly in agreement as well, but just to be clear - our 10.5 build capabilities will be deprecated and internal testing on 10.5 will no longer occur. My only lingering concern is if leaving 10.5 in place on the ESR may somehow make it more difficult to backport security/stability fixes in the future. If that doesn't worry anybody, then I think it's a fine plan.

-Alex

[Cameron Kaiser]

For some reason my post got eaten, so apologies for any duplicates.
However, if a bug requires landing on the ESR branch that would
necessitate eliminating a 10.5 workaround, we will eat such bugs
ourselves and/or construct an alternate patch; I consider this part of
the cost of doing business. I would appreciate being cc'ed on them
though.

Cameron Kaiser

[land....@gmail.com]

Could you please continue supporting 10.6.5 at least?

[Alex Keybl]

Thanks to everyone who joined this discussion. We've now moved forward with disabling OS X 10.5 support for FF17 in [1]. Per discussion here, we will strive to leave code in place through the 17 cycle, but if it becomes difficult to accomplish necessary work, we may end up breaking things to advance our goals for supported Mac versions.

If you are interested in following along with plans to communicate this support change, please see [2].

-Alex

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=772682
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=774509

On Jun 21, 2012, at 3:37 AM, Josh Aas wrote:

> [This is an updated copy of my last proposal. The major change is that this targets Firefox 17 instead of Firefox 16. Other data has been updated and made more accurate as well.]
>
> I'd like to propose that we remove support for Mac OS X 10.5 in Firefox 17, which should ship on or near November 13, 2012. To be clear: this is not a decision that has been made, I’m proposing it here in order to get feedback.
>

> First, some facts:
>
> =================================
> Mac OS X Release Dates) 10.5 was released in October of 2007, 10.6 was released in June of 2009, 10.7 was released in July of 2011. Mac OS X 10.8 will be released during the summer of 2012.
>
> Mac OS X User Breakdown) Mac OS X users make up 4.6% of Firefox 13 (current stable) users as of June 21, 2012. Of those Mac OS X users, 17% are on Mac OS X 10.5, 35% are on Mac OS X 10.6, and 48% are on Mac OS X 10.7.
>
> Trends) Mac OS X 10.5 users have been declining by 1% per month (as a share of our total Mac OS X users). This, combined with the impact of the release of Mac OS X 10.8, means that Mac OS X 10.5 users will likely make up around 10% of Mac OS X users when Firefox 17 ships.
> =================================
>
> Apple releases new versions of its operating systems relatively quickly and each new version contains significant changes that we must adapt to. This requires resources, and with limited resources this sometimes means we have to make tough decisions about where to invest.
>
> We still have significant integration work to do for Mac OS X 10.7 and we’re getting more for Mac OS X 10.8. Currently we have to go back and make sure we didn’t cause problems on Mac OS X 10.5 every time we do integration work for newer OS versions. In addition to the core Mac OS X platform layer (Cocoa widgets), subsystems such as plugins and graphics are affected by the Mac OS X 10.5 requirement.
>
> Build, release, and testing infrastructure resources are also consumed by the Mac OS X 10.5 requirement.
>
> There are already some significant ways in which Firefox on Mac OS X 10.5 has fallen behind Firefox on newer versions of Mac OS X. Accelerated compositing, WebGL, and out-of-process plugins are not available on Mac OS X 10.5.
>
> Google has already announced their plans to drop Chrome’s support for Mac OS X 10.5 in Chrome 22 [1]. Chrome 22 will likely be released on or around October 19, 2012.
>
> Finally, Apple has already stopped supporting Mac OS X 10.5, and Adobe will likely stop shipping security updates for Flash on Mac OS X 10.5 soon. While Apple does not officially drop support for older OS versions, they have stopped shipping security updates and updating applications like Safari.
>
> [1] https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/3nUlhuHbf0Q

[Mark Banner]

On 19/07/2012 21:38, Alex Keybl wrote:
> Thanks to everyone who joined this discussion. We've now moved
> forward with disabling OS X 10.5 support for FF17 in [1]. Per
> discussion here, we will strive to leave code in place through the 17
> cycle, but if it becomes difficult to accomplish necessary work, we
> may end up breaking things to advance our goals for supported Mac
> versions.

Will we also be stopping the universal binaries? AIUI the 32 bit part
was only kept around for the 10.5 support, and running 32 bit on 10.6 is
unsupported.

Hence I don't think we need the 32 bit part any more?

If we do drop that, then I believe that'd be a significant reduction on
our build & release systems...

Mark.

[Boris Zbarsky]

On 7/30/12 4:23 AM, Mark Banner wrote:
> Will we also be stopping the universal binaries? AIUI the 32 bit part
> was only kept around for the 10.5 support

It was also kept around to allow running 32-bit plug-ins in a 32-bit
plug-in process, no?

-Boris

[Mike Hommey]

On Mon, Jul 30, 2012 at 09:23:43AM +0100, Mark Banner wrote:
> On 19/07/2012 21:38, Alex Keybl wrote:
> >Thanks to everyone who joined this discussion. We've now moved
> >forward with disabling OS X 10.5 support for FF17 in [1]. Per
> >discussion here, we will strive to leave code in place through the 17
> >cycle, but if it becomes difficult to accomplish necessary work, we
> >may end up breaking things to advance our goals for supported Mac
> >versions.
>
> Will we also be stopping the universal binaries? AIUI the 32 bit
> part was only kept around for the 10.5 support, and running 32 bit
> on 10.6 is unsupported.
>
> Hence I don't think we need the 32 bit part any more?

There are two things for which 32-bit is required: 32-bits-only Mac
(they exist, and they run 10.6 just fine ; not sure about 10.7), and
32-bits plugins on 64-bits hosts. I doubt we can drop universal binaries
just yet.

Mike

[Alex Keybl]

+1 to what Mike said. https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard

> Mac OS X Snow Leopard (10.6) was the last release of Mac OS X to support the 32-bit Intel Core Solo and Intel Core Duo CPUs.


Steven would have more info on 32-bit plugins on a 64-bit host, as I'm not sure any of the 32-bit binary/library slices are ever loaded on a 64-bit machine (could definitely be wrong though).

-Alex

On Jul 30, 2012, at 1:29 AM, Mike Hommey <m...@glandium.org> wrote:

> On Mon, Jul 30, 2012 at 09:23:43AM +0100, Mark Banner wrote:

>> On 19/07/2012 21:38, Alex Keybl wrote:
>>> Thanks to everyone who joined this discussion. We've now moved
>>> forward with disabling OS X 10.5 support for FF17 in [1]. Per
>>> discussion here, we will strive to leave code in place through the 17
>>> cycle, but if it becomes difficult to accomplish necessary work, we
>>> may end up breaking things to advance our goals for supported Mac
>>> versions.
>>
>> Will we also be stopping the universal binaries? AIUI the 32 bit
>> part was only kept around for the 10.5 support, and running 32 bit
>> on 10.6 is unsupported.
>>
>> Hence I don't think we need the 32 bit part any more?
>

> There are two things for which 32-bit is required: 32-bits-only Mac
> (they exist, and they run 10.6 just fine ; not sure about 10.7), and
> 32-bits plugins on 64-bits hosts. I doubt we can drop universal binaries
> just yet.
>
> Mike

[Hubert Figuière]

On 30/07/12 01:29 AM, Mike Hommey wrote:
> There are two things for which 32-bit is required: 32-bits-only Mac
> (they exist, and they run 10.6 just fine ; not sure about 10.7), and
> 32-bits plugins on 64-bits hosts. I doubt we can drop universal binaries
> just yet.

10.7 does not run on 32-bits machine anymore.

Hub