I'd still like to drop support for Mac OS X 10.4 in Gecko 1.9.2, I
don't want to be worrying about 10.4 until 2012. We have a little more
information now and I'd appreciate feedback again. Please make sure to
read everything I've written below before replying. Thanks!

=======================
Mac OS X Release Status
=======================

First, a quick update on the state of Mac OS X releases. 10.5 has been
out since October 2007, which means it has now been out for about 1.5
years. 10.6 is probably going to be released within 2-3 months,
relatively early on in the development cycle for Gecko 1.9.2.
Historically when a major OS release like that happens Apple stops
shipping regular security updates for the operating system 2 releases
behind the new one, in this case 10.4. Usually the last security
updates for the release 2 behind current come out within a few months
of a major release.

Things could be a little different with 10.4. It seems likely that
Safari 4 will support 10.4, if it does then we will be supporting 10.4
just as long as Apple does via Firefox 3.5, due out around the same
time as Safari 4.

======================
10.4 Support Timelines
======================

If we drop support for 10.4 in Gecko 1.9.2 then 10.4 users will be
supported until approximately Q1 2011 via Firefox 3.5. Our 10.4
support would end a little over 3 years after the last copy of 10.4
shipped.

If we do not drop 10.4 support in Gecko 1.9.2 we will probably end up
supporting 10.4 until approximately Q1 2012. Assuming Firefox ships
with Gecko 1.9.2 in Q2 2010, it'll be our main release for
approximately a year and then we'll continue to support it for 6
months after that.

Again, if we drop 10.4 support in Gecko 1.9.2 then our support
timeline for 10.4 via Firefox 3.5 matches up with Apple's support
plans for 10.4 via Safari 4. They'll be released around the same time
and supported for about the same amount of time.

==================
Per-OS User Counts
==================

Right now 10.4 users make up 36% of total Mac OS X users, 1.97 million
in our blocklist, down from 2.1 million five months ago in November
2008.

Right now 10.5 users make up 64% of total Mac OS X users, 3.47 million
in our blocklist, up from 2.6 million five months ago in November
2008.

If compiling Mozilla stats was lawyerin' I'd warn you with "IANAL". I
think these numbers are pretty close though.

Obviously dropping 36% of our users is not acceptable, but we're not
talking about dropping support for them for a while. I think after
another 1.6 years and the release of 10.6 this summer that number will
be pretty low. 10.4 users will also be without security updates at
that point, most likely even for Safari 4.

==========
10.5+ APIs
==========

One major benefit of moving to 10.5 as a minimum is using 10.5+ APIs
without runtime detection and build-time SDK trickery. A good example
of this is Core Text, which is not available on 10.4. We actually have
a Core Text implementation in our tree now, it builds when the 10.5
SDK is used (not the case for official builds and tinderboxes right
now). In my experiences it is pretty fast and stable, my performance
numbers show it is equally as fast as ATSUI but that should improve in
10.6 and we haven't done much in the way of optimizing our Core Text
implementation. If we want to use Core Text in Gecko 1.9.2 without
dropping 10.4 support we have to target the 10.5 SDK at build time
even though we support 10.4, possible but likely messy, and we'd have
to ship 2 text backends. ATSUI for 10.4 and Core Text for 10.5 and
10.6. We'd choose an active text backend using runtime detection. This
means we'd be running totally different text backends on different
versions of Mac OS X. Eww.

There are quite a few other places where we could easily move to
better APIs if 10.5 was our minimum. Because of 10.4 our menu system
has to use Carbon events to figure out when menus open and close,
"menuWillOpen:" and "menuDidClose" are 10.5+. We also have to use
Carbon events to track the mouse moving over native menu items because
native menu items don't have views until 10.5. We could also clean up
and improve a lot of our keyboard/IME code if we could use Input
Method Kit, which was introduced in 10.5. The Firefox 3 RC "key hell"
was caused in part by Apple's shoddy key/IME support prior to 10.5.
There are also many new printing-related APIs in 10.5 that will be
very useful. I tried to update our Mac OS X printing implementation
last year, it was painful without 10.5+ APIs and I haven't gone back
to the work. I'm sure Vlad could list some 10.5+ graphics-related APIs
we'd like to use and there are other example scattered around the
tree.

In the simplest cases we could do runtime call detection to call the
10.5+ APIs and in other cases we'd have to add some complex ifdef'd
refactoring based on how the native APIs work. In all cases here QA
and code complexity would take a hit since having two ways of doing
the same thing makes code more complex and testing harder.

As for the importance of moving to new APIs on Mac OS X in particular,
Vlad described the situation well in the last discussion: "one major
difference between Apple and Microsoft is that the APIs that we depend
on under Windows are often very old and very stable, whereas on the
OSX side they're all under pretty heavy bugfix and development churn.
Supporting older OS releases hurts us much more due to a need to work
around the older bugs, as well as preventing us from taking advantage
of newer APIs."

=======
GCC 4.2
=======

Making 10.5 our minimum OS also allows us to use gcc 4.2 to produce
builds. According to the Xcode 3.1 release notes: "Note that neither
gcc-4.2 nor llvm-gcc-4.2 will compile code against the 10.4u or
earlier SDK, or deploy for Mac OS X 10.4 or earlier."

I did some performance tests, gcc-4.0 Gecko vs. gcc-4.2 gecko with no
compiler flag changes except targeting 10.5 in the gcc-4.2 case, same
text backend (ATSUI) for both compilers. Tp, Ts, Tsvg, and Twinopen
were about the same, maybe a slight edge to gcc-4.2. In the Tjss tests
gcc-4.2 is faster than gcc-4.0 by quite a bit. Here are the test
results for the Tjss test from talos:

http://joshaas.net/mozilla/gcc40-tjss.csv
http://joshaas.net/mozilla/gcc42-tjss.csv

gcc-4.2 also had a noticeable advantage in the Tgfx and sunspider
tests, though the difference was not as big as in the tjss test.

Zip files with full talos results are here:

http://joshaas.net/mozilla/talos-gcc40-output.zip
http://joshaas.net/mozilla/talos-gcc42-output.zip

If I've made a mistake interpreting these numbers please let me know.

Apple's compilers for 10.5+ will probably improve over time as well,
we might even have better gcc-4.2, gcc-4.3, gcc-4.4 or llvm options by
the time 1.9.2 ships. There aren't going to be better options for 10.4
and Apple's gcc-4.0 compiler is almost certainly not going to get any
better. I don't want to be stuck with gcc-4.0 until 2012.

======
64-bit
======

Making 10.5 our minimum also makes a 64-bit port much easier since
10.5 includes a full 64-bit application stack, though I don't want
people to get too distracted by this like in our last conversation. It
is too early to say whether or not we'll want to ship a 64-bit Mac OS
X version of Firefox.next, but whether or not we do that the prudent
move is to make significant progress and probably complete a 64-bit
port for Gecko 1.9.2. Not doing so would take away the option of
shipping a 64-bit build later on in the release cycle. I don't think
we need to make a decision about shipping 64-bit now but we should be
prepared as early as possible. As a further aside, our 32-bit builds
benefit from much of the work done to get ready for 64-bit as old code
gets re-examined, improved, and moved to newer APIs.

Why should we port Gecko 1.9.2 to 64-bit now if we don't know that
we'll ship a 64-bit build? Because we're going to have to do it
eventually and unlike porting to 64-bit Windows or Linux, porting to
64-bit Mac OS X means rewriting a lot of code and moving to very
different APIs. This takes a lot of time and effort and the sooner we
let Apple know about any problems in this major transition (especially
missing functionality) the better. Also, it looks like 64-bit
applications are the norm on 10.6. What exactly that means for us is
yet to be determined, but there will almost certainly be benefits for
64-bit applications. That could mean performance wins from not loading
32-bit libraries, 64-bit libraries being cache-hot more often, and 64-
bit will probably generally get more attention from Apple than 32-bit.
Again, not to get too far off track because none of this necessarily
means anything at this point, but here are some quotes from Apple and
ARS Technica on the subject:

Apple:
"The 64-bit Objective-C ABI is generally unlike the 32-bit ABI. The
new ABI provides new features, better performance, and improved future
adaptability. All aspects of the 64-bit ABI are private and subject to
future change. Forthcoming documentation will describe the ABI for the
use of compilers and developer tools only."

http://developer.apple.com/releasenotes/Cocoa/RN-ObjectiveC/index.html

Ars Technica:
"In Cocoa, deprecated APIs were simply not ported to 64-bit. The
Objective-C runtime is all-new for 64-bit, with a new ABI, faster
dispatching, zero-cost exceptions, and public APIs for introspection
built on top of newly opaque internal structures."

==========
Conclusion
==========

I think dropping 10.4 support in 1.9.2 will allow us to make the most
efficient use of our resources and focus on quality and performance
for the vast majority of the users we'll have in 2011. We have some
stiff competition on the platform and we're going to need all of the
advantages we can get.

Technically we could move ahead with most of our plans without
dropping support for 10.4. However, I don't think the sacrifices we
would have to make are worth it. Quality and our feature set ...

read more »

Obviously, you have much evidence in support of dropping support for
10.4, so I can't say I blame you for wanting to.

But let me give you my perspective:
I have two computers running 10.4; the first one (PPC) was purchased
in November 2005, the second (Intel) in August 2007. Both cost
approximately $2000 each. I missed the cutoff for a new feature by a
couple of months both times (the Intel switch in January 2006 and the
release of 10.5 in October 2007). To upgrade either of these systems
now (or when 10.6 comes out), it would cost me another $100 or $200.
My current main computer is less than two years old! On the flipside,
Windows XP came out in 2001 and Firefox is still supporting it 8 years
later. (Sure, there have been 3 SPs since then, but they were all free
upgrades!) And just because an OS stops getting security updates
doesn't mean that all the computers using it suddenly disappear off
the map. Heck, look at the proliferation of IE6 and how annoying that
is.... But I digress.

Suffice to say, I will be very disappointed if I can't upgrade to
Firefox 3.6 or Firefox 4 next year.

But that's just my two cents.

Gordon

Is that a Firefox problem or just what you get when you buy Apple? You
can always load Linux on that box when Apple stops supporting it.

I agree with Josh.

I think it makes sense to support an OS version for as long as Apple
does.  We're already doing this on the trunk and the 1.9.X branches --
we started by dropping support for 10.3 when Apple did.  Even when we
did support older OS versions (on the 1.8.X branches), compatibility
with the oldest of them tended to tail off over time (I remember
seeing
this on my OS X 10.2.8 partition).

We've got plenty of stuff on our plate now.  Because Apple has used
the
transition to 64-bit as an opportunity to do a wholesale cleanout of
old
APIs, that task is a particularly large one.  We don't need any extra
distractions :-)

Is our plan to be no better than the pre-installed browser of a system
in terms of support cycles?

You assume 1-year development cycles for every release here when the
intent had been there ion the beginning of 1.9.1 to shorten those to as
little as 6 months - not sure what happened to that target, maybe we
just have dropped idea that anyways. It's hjad to make such estimates as
you do without even knowing what the target for 1.9.2 itself is in terms
of release dates.

So 6% less people are using Firefox on 10.4 after 5 months, which is a
quite slow decrease for a non-current version if the new version is
apparently that much better. Of course, those 5 months could be
completely unrepresentative of what's to come when 10.6 is released at
some point, IIRC we don't even know yet when that will be.

What is "pretty low"? Where is the line where it's acceptable? How does
this compare to the situation not too long ago when we dropped 10.3 support?

Good to see and know that there are actually compelling technical
reasons, unlike in the case of other old versions of different OSes we
discussed recently.

Technically, I think this is very compelling for the reasons you cited,
esp. the problems of continuing the support of Tiger you laid out. So I
guess it comes down to weighing technical needs against market shares
and possibly pissed off users (and and even developers or other
contributors, which are the two groups usually hit first by such
decisions). This is not an easy task and decision.

Robert Kaiser

Overall I think there's a lot of technical reasons why 10.5 should be  
a new baseline, and the number of users is small and diminishing in  
any case, so I definitely support this from the Firefox side.

On 24-Apr-09, at 3:08 PM, Robert Kaiser wrote:

No one has made any argument for doing better, other than arguments  
around capturing shrinking market share that the OS vendors don't care  
about... No one's actually explained why that's a good use of our  
resources, they've just demanded their free lunch.

I would assume fall 2010 for end of 1.9.1 support.  The intent is to  
ship the next version of Firefox in the first half of 2010.  I've  
cited this date multiple times in the Win2k thread.

We can't accurately predict trend data off five months of data.  That  
said, if we took this slow decline over time, we'd be under half a  
million in 18 months.  10.6 likely changes this game substantially,  
and will only increase updates/hardware refreshes.  A better figure is  
that this is less than 1% of our users, and we can confidently say  
that in the next year we'll see that number halved.  I don't have time  
to get precise stats, but that's in line with the 10.3 drop-off, IIRC.

I think that there's no hard number that we can argue for.  I do think  
that once we get under half a percentage point, we want to look very  
hard at cost/benefit.  If it takes a full time developer's worth of  
time just for compatibility, and costs us substantially for  
performance on top of that, I think the deck's stacked against an OS.

I don't think any developers are stuck on 10.4.  If they are, I'm sure  
we could help them out via community giving.

Users will be pissed off.  That's just the way it works, but a huge  
number of apps seem to be 10.5-only these days anyway, so we're just  
another tree in the forest, and not even for another year or so.

-- Mike

I'm pretty sure there a few in our volunteer community that currently
don't have plans for switching away from Tiger but probably need to
think about it if trunk doesn't support it any more (as I said, devs are
the first people to be hit, of course).
Good to know that community giving might be an option for them - I hope
that includes people who are not contributing to Firefox directly but
mainly e.g. to Thunderbird, Calendar or SeaMonkey.

Robert Kaiser

On Apr 24, 2:32 am, josh...@gmail.com wrote:

Actually Core Text _is_ available on 10.4,  but as a private
framework.
I've not yet tried to use it myself,  but a glance at the 10.5 docs
and headers
together with comparing to the symbols exported by the 10.4 version
suggests
it may simply be a case of creating the necessary header file.

The other option is to use CocoaText (or a thin wrapper around it),
since Core Text
seems to be modeled on it.  So with a set of wrapper classes,  the
10.4 version
would map the wrappers to CocoaText,  and the 10.5 versions to
CoreText.

DF

Maybe mozilla could give grants to a few selected productive
contributors to allow them to upgrade their OSX installs.

/ Jonas

On May 20, 2:11 am, Simon Paquet <si...@gmx.de> wrote:

This is a serious chuck of people.  What is the trend for those users
over the last year?  Can we make a prediction of the number of 10.4
users at the time support would be phased out (i.e. Q1 2011)?  I think
if we can get the number below 5% of Mac users then we could morally
justify our decision to drop 10.4 support.

I don't think there's a moral issue here at all, just an economic
(allocation of resources, not necessarily $$$) one.

Mike

If we do not have the resources to allocate to 3 versions of Mac OS,
then I would say we have an ethical obligation to inform our users and
phase out support.  Frankly, I think it will cause more of a problem
if we tell users we can support 10.4 when we can't than if we are up
front and tell them "We just don't have the resources to support three
Mac platforms at this time.  As a result, we will be phasing out
support for Tiger to conclude Q1 2011", or something like that.

On May 20, 2009, at 2:04 PM, Mike Shaver wrote:

Beta users, using 10.4, on the 3.0 line amount to about 25% of all Mac  
users on that line.
Nightly users, using 10.4, on the 3.0 line amount to about 25% of all  
Mac users on that line.

Beta users, using 10.4, on the 3.5 line amount to about 13% of all Mac  
users on that line.
Nightly users, using 10.4, on the 3.5 line amount to about 10% of all  
Mac users on that line.

Nightly users, using 10.4, on the 3.6 line amount to about 8% of all  
Mac users on that line.

Hope that data helps,

-Sam

That would surely be an interesting option, if those cases come up, I'll
point them to that.

Robert Kaiser