Mac OS X 10.4 "Tiger" Support Post-1.9.1
jos...@gmail.com
right thing to do. I would appreciate feedback, please make sure to
read everything I've written below before replying. Thanks!
=== Timeline and Users ===
Mac OS X 10.4 was released in April of 2005. It was Apple's fifth
major Mac OS X release and Apple will release their seventh, Snow
Leopard, in 2009.
The first Gecko products that would not support 10.4 will be released
in late 2009 or even 2010. 10.6 will be out by then and 10.4 market
share will be low.
Right now, approximately...
10.5 = 2.4M users
10.4 = 1.9M users
10.3 = 0.3M users
I believe that after one more year of transition time plus the upgrade
rush that will be caused by the release of 10.6, we will be able to
drop support for 10.4 in Gecko.
Remaining 10.4 users will still have access to the Gecko-1.9.1
products, which are fantastic.
Also note... While it is Apple's policy that they never officially
drop support for any version of Mac OS X, they effectively only
support the release prior to the current one. By the time we would
ship without 10.4 support, Apple will have shipped 10.6 and
effectively stopped supporting 10.4. Officially supporting our product
on an operating system that does not receive security updates is not
desirable.
=== API support ===
Apple is deprecating much of Carbon and some other APIs like ATSUI.
Finding replacements is much harder on 10.4 than it is on 10.5. Apple
wants to settle on the "Core..." APIs, at least for longer than they
have settled on any other APIs in the past few years. CoreText is one
API that we're particular interested in as it offers significant
performance advantages. CoreText is not available on 10.4. In
addition, 10.5 offers a more complete, faster, and less buggy
CoreGraphics API. I'll let Vlad go into the details of this if he
wants to. Of course 10.5 also has a better Cocoa API in general.
=== 64-bit ===
Developing a 64-bit version of Gecko for Mac OS X will be easier
without us having to support 10.4. 10.5 includes full 64-bit
application support and 10.4 does not. 10.6 will not only include
improved 64-bit support, but all signs indicate that it will run 64-
bit versions of applications by default. This means that an
application without a 64-bit binary in the universal bundle will
necessitate loading the 32-bit runtime libraries on 64-bit machines,
and I don't want Firefox to be the app that does that to people. 64-
bit is a priority for us even if our predictions about 10.6 turn out
not to be true - 64-bit is the future for Mac OS X desktop
applications.
=== QA and Developer Resources ===
Our support matrix is also about to get more complicated and dropping
support for 10.4 will simplify things. In 2009 we're going to have to
test:
- 10.4 PPC
- 10.4 x86
- 10.5 PPC
- 10.5 x86
- 10.5 x86_64
- 10.6 PPC (unclear, we are assuming 10.6 will support PPC at this
point)
- 10.6 x86
- 10.6 x86_64
I don't believe 10.4 support is a wise use of QA and developer
resources in 2009.
======
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 would
suffer from significantly increased code complexity, slower
development, and thinned QA coverage. Furthermore, WebKit is
aggressively taking advantage of new technologies and it will be hard
to keep up if we keep ourselves committed to 10.4 support.
A note about comparisons to our Windows support situation... The
situation with Mac OS X is very different than it is with Windows. One
major difference is the number of supported architectures - we already
support 2 for Mac OS X and we're going to add a third sooner or later.
We only support one architecture for Windows. The second major
difference is that Apple effectively supports its operating systems
for far less time than Microsoft does. Users are expected to, and do,
move to newer version of Mac OS X faster than Windows users move to
newer versions of Windows. This is because Mac OS X is a much younger
operating system and Apple's development pace is much more aggressive
than Microsoft's.
Questions? Comments? Sorry for the long read but I want to give all
the info I have for consideration. I'd like to get this decision taken
care of by the time we start post-1.9.1 hacking and branch
infrastructure setup so we can get right to work without wasting time.
Justin Dolske
> I think dropping support for Mac OS X 10.4 after Gecko 1.9.1 is the
> right thing to do.
Just to be clear, this would be 1.9.2 then?
Justin
jos...@gmail.com
> Just to be clear, this would be 1.9.2 then?
Sure, though I'm not sure we've committed to calling it that or having
such a thing.
Robert Accettura
> I think dropping support for Mac OS X 10.4 after Gecko 1.9.1 is the
> right thing to do. I would appreciate feedback, please make sure to
> read everything I've written below before replying. Thanks!
>
>
This seems pretty reasonable considering the cutoff machine for 10.4 -->
10.5 I think was the Blue & White G3 which was up to 400MHz IIRC and
first shipped in Jan 1999. It will be 10 years old in Jan.
While not very relevant today, I'm more concerned about what will happen
during the next phase if 10.6 doesn't support PPC (which many question
if it will support). There's a fair number of dual processor G5's that
cost a few thousand dollars and are perfectly capable machines. I think
this will be a more controversial call (on Apple's part, and on
Mozilla's part depending on the outcome).
-R
Robert Accettura
> I think dropping support for Mac OS X 10.4 after Gecko 1.9.1 is the
> right thing to do. I would appreciate feedback, please make sure to
> read everything I've written below before replying. Thanks!
>
Boris Zbarsky
> This seems pretty reasonable considering the cutoff machine for 10.4 -->
> 10.5 I think was the Blue & White G3 which was up to 400MHz IIRC and
> first shipped in Jan 1999. It will be 10 years old in Jan.
The mimimal hardware requirement for Leopard is an 866MHz G4. There are
plenty of dual-processor Graphite G4s that don't satisfy that
requirement and were certainly selling much later than 1999. In fact,
the first Power Mac that satisfies that requirement is the
top-of-the-line Quicksilver G4, first available July 2001. On the
laptop front, the first laptop that can run Leopard is an "Antimony"
TiBook, first available Nov 2002.
But of more interest is not what the first machine you can't upgrade to
10.5 is but what the latest machines to ship with 10.4 were (and which
would therefore require a somewhat expensive OS upgrade to get a newer
Firefox while otherwise being perfectly serviceable). Those would
include at least the original CoreDuo Intel-based MacBooks (still being
sold with Tiger until October 2007, 2 years ago).
I'm not saying that means we shouldn't drop support, but any argument
that makes it sound like this would only affect users of Blue&White G3's
is misguided at best.
> There's a fair number of dual processor G5's that
> cost a few thousand dollars and are perfectly capable machines.
Honestly, pretty much the same thing could be said today about the
dual-processor G4s at 800Mhz...
-Boris
Samuel Sidler
> The first Gecko products that would not support 10.4 will be released
> in late 2009 or even 2010. 10.6 will be out by then and 10.4 market
> share will be low.
Is this assumption using percentages or total numbers? I ask because a
lot of 10.4 users I know *aren't* upgrading and have no intention to,
but given Apple's growth in the market, the overall percentage of 10.4
users is going down fast while the total number is declining much
slower.
Put another way: Add 2m new users of Mac OS X (specifically on 10.5)
every quarter and you can make 10.4 usage look like nothing in a
couple of years.
If our users haven't migrated and we still have, say, 1.5m users, will
we change this decision? How much does Firefox usage on 10.4 and its
downward trend relate to when we'll make this switch?
> Right now, approximately...
> 10.5 = 2.4M users
> 10.4 = 1.9M users
> 10.3 = 0.3M users
How does this compare with historical numbers? What's the uptake in
our users from off of 10.3? How about off of 10.4? What kind of trends
exist that we should be looking at to determine where usage will be in
a year? (I'm guessing a year is about when a potential 3.next will ship)
> I believe that after one more year of transition time plus the upgrade
> rush that will be caused by the release of 10.6, we will be able to
> drop support for 10.4 in Gecko.
The transition from 10.4 to 10.5 was a lot faster because:
a) 10.4 had been released for two and a half years before 10.5
shipped so the $129 upgrade cost felt worth it for consumers
b) 10.5 had significant features over 10.4
c) Percentage-wise, it seemed faster because Apple was/is selling
more machines than ever before
d) There's incidental evidence that Mac users upgrade every other
release so many 10.3 users were upgrading
For 10.5 -> 10.6 this doesn't seem as likely.
a) 10.6 is expected to ship in mid-2010 (a year and a half after
10.5)
b) 10.6 is considered a more moderate upgrade with fewer new big
user-end features (64 bit doesn't count, for example)
c) Apple will likely
d) It's likely that users won't justify the cost of upgrading given
the current recession, especially if 10.4 works just fine and Apple
continues to support it
I'd also note that, after the initial wave of users upgrading, there
are very few users who upgrade from one major release to another
before purchasing a new machine.
This sentence also makes it sound like you want to drop support in a
year. What does that mean practically? No longer working on 10.4 now
or starting November 2009?
> Remaining 10.4 users will still have access to the Gecko-1.9.1
> products, which are fantastic.
Until 6 months after we ship 1.9.next...
> Also note... While it is Apple's policy that they never officially
> drop support for any version of Mac OS X, they effectively only
> support the release prior to the current one. By the time we would
> ship without 10.4 support, Apple will have shipped 10.6 and
> effectively stopped supporting 10.4. Officially supporting our product
> on an operating system that does not receive security updates is not
> desirable.
Kind of... I agree that Apple doesn't officially drop support for any
version of Mac OS X, however, they have offered updates for 10.3 after
10.5 shipped. Notably a security update on November 14, 2007 and a
QuickTime update (to fix security bugs and add features) on January
15, 2008.
See this and related documents: http://support.apple.com/kb/HT1222?viewlocale=en_US
It's unclear what their methodologies are (unless you know something I
don't), but my guess is that they base this on the user base of a
given OS. We don't know what that means for 10.4 because we don't know
how many 10.4 users there are.
> === API support ===
>
> Apple is deprecating much of Carbon and some other APIs like ATSUI.
> Finding replacements is much harder on 10.4 than it is on 10.5. Apple
> wants to settle on the "Core..." APIs, at least for longer than they
> have settled on any other APIs in the past few years. CoreText is one
> API that we're particular interested in as it offers significant
> performance advantages. CoreText is not available on 10.4. In
> addition, 10.5 offers a more complete, faster, and less buggy
> CoreGraphics API. I'll let Vlad go into the details of this if he
> wants to. Of course 10.5 also has a better Cocoa API in general.
Where do we want to use CoreText? Bug numbers would be preferred
here... Do we know for sure that there's a performance advantage? How?
I'd like to see numbers here, not just guesses based on what we think
the API will do for us.
> === 64-bit ===
>
> Developing a 64-bit version of Gecko for Mac OS X will be easier
> without us having to support 10.4. 10.5 includes full 64-bit
> application support and 10.4 does not. 10.6 will not only include
> improved 64-bit support, but all signs indicate that it will run 64-
> bit versions of applications by default. This means that an
> application without a 64-bit binary in the universal bundle will
> necessitate loading the 32-bit runtime libraries on 64-bit machines,
> and I don't want Firefox to be the app that does that to people. 64-
> bit is a priority for us even if our predictions about 10.6 turn out
> not to be true - 64-bit is the future for Mac OS X desktop
> applications.
I think the line "10.5 includes full 64-bit application support" is a
bit dubious, but prove me wrong. What about Carbon APIs? Aren't we
still using some Carbon APIs? How will we move those over for 10.5
users?
64-bit may be the future, but I haven't heard what it will do
practically for users of Firefox. We need to switch, yes. But is the
cost of switching now worth the benefit? And what *is* the benefit for
end users?
> === QA and Developer Resources ===
>
> Our support matrix is also about to get more complicated and dropping
> support for 10.4 will simplify things. In 2009 we're going to have to
> test:
>
> - 10.4 PPC
> - 10.4 x86
> - 10.5 PPC
> - 10.5 x86
> - 10.5 x86_64
> - 10.6 PPC (unclear, we are assuming 10.6 will support PPC at this
> point)
> - 10.6 x86
> - 10.6 x86_64
Kind of... As I said above, it's not clear we need to move to 64-bit
immediately (we don't have supported 64-bit builds on either Windows
or Linux despite them both support it).
Additionally, QA has already been through the testing cycle of 10.2,
10.3, 10.4 (PPC/Intel), and 10.5 (PPC/Intel). Adding one more OS isn't
that much more additional work and with community support (since most
of them are filing platform-specific bugs), we're at the same place we
were before.
This long list actually makes me think we shouldn't support 64-bit
until later. It doesn't make me think we should drop 10.4 support.
> 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 would
> suffer from significantly increased code complexity, slower
> development, and thinned QA coverage. Furthermore, WebKit is
> aggressively taking advantage of new technologies and it will be hard
> to keep up if we keep ourselves committed to 10.4 support.
WebKit also supports 10.4... The Safari 4 beta does as well and that's
currently unreleased (i.e., not released to the general public). Do we
have any idea when they'll drop support? My hunch is no.
Source: http://www.macrumors.com/2008/06/10/apple-seeds-safari-4-to-developers/
--
Overall, I'm not vehemently against dropping support for 10.4, I just
don't think everything has been considered. Making this decision now,
when over 40% of our users are on 10.4 doesn't seem like the right
move. In the world of 80/20s, we'd still be supporting that 10.4.
My gut says we should wait another cycle.
-Sam
Samuel Sidler
> But of more interest is not what the first machine you can't upgrade
> to 10.5 is but what the latest machines to ship with 10.4 were (and
> which would therefore require a somewhat expensive OS upgrade to get
> a newer Firefox while otherwise being perfectly serviceable). Those
> would include at least the original CoreDuo Intel-based MacBooks
> (still being sold with Tiger until October 2007, 2 years ago).
2007 was 1 year ago, fwiw... We'd be offering these users probably two
and a half years of support.
(Time flies. ;) )
-Sam
Robert Kaiser
> We only support one architecture for Windows.
Erm, so Win2k, WinXP, Vista, and WinMobile are all one architecture, and
much more similar than Tiger is to Leopard and Snow Leopard?
Robert Kaiser
timeless
intent of using it to develop firefox/camino (products which are
free). I didn't sign up to buy a new os every second year. And i don't
look forward to paying 200usd (depending on the stupid european tax -
EUR to USD exchange is) just for a temporary extension so i can use
ff3 but not develop the next one.
less seriously
how about we develop a leasing system where at the end of life we
donate the macs w/ a skyfire like client to schools or old age homes.
That way developers aren't spending 1500(cur) semiannually and at the
same time grow our base :).
i agree that we should be looking at the last date of sale and not the
first date.
Personally, i'm in the camp where i'm more likely to buy a new
computer than pay for an upgrade.
On 11/8/08, Samuel Sidler <s...@mozilla.com> wrote:
> On Nov 7, 2008, at 3:02 PM, jos...@gmail.com wrote:
>
>> The first Gecko products that would not support 10.4 will be released
>> in late 2009 or even 2010. 10.6 will be out by then and 10.4 market
>> share will be low.
>
> Is this assumption using percentages or total numbers? I ask because a
> lot of 10.4 users I know *aren't* upgrading and have no intention to,
> but given Apple's growth in the market, the overall percentage of 10.4
> users is going down fast while the total number is declining much
> slower.
>
> Put another way: Add 2m new users of Mac OS X (specifically on 10.5)
> every quarter and you can make 10.4 usage look like nothing in a
> couple of years.
>
> If our users haven't migrated and we still have, say, 1.5m users, will
> we change this decision? How much does Firefox usage on 10.4 and its
> downward trend relate to when we'll make this switch?
>
>> Right now, approximately...
>> 10.5 = 2.4M users
>> 10.4 = 1.9M users
>> 10.3 = 0.3M users
>
> How does this compare with historical numbers? What's the uptake in
> our users from off of 10.3? How about off of 10.4? What kind of trends
> exist that we should be looking at to determine where usage will be in
> a year? (I'm guessing a year is about when a potential 3.next will ship)
>
>> I believe that after one more year of transition time plus the upgrade
>> rush that will be caused by the release of 10.6, we will be able to
>> drop support for 10.4 in Gecko.
>
> The transition from 10.4 to 10.5 was a lot faster because:
> a) 10.4 had been released for two and a half years before 10.5
> shipped so the $129 upgrade cost felt worth it for consumers
> b) 10.5 had significant features over 10.4
> c) Percentage-wise, it seemed faster because Apple was/is selling
> more machines than ever before
> d) There's incidental evidence that Mac users upgrade every other
> release so many 10.3 users were upgrading
>
> For 10.5 -> 10.6 this doesn't seem as likely.
> a) 10.6 is expected to ship in mid-2010 (a year and a half after
> 10.5)
> b) 10.6 is considered a more moderate upgrade with fewer new big
> user-end features (64 bit doesn't count, for example)
> c) Apple will likely
> d) It's likely that users won't justify the cost of upgrading given
> the current recession, especially if 10.4 works just fine and Apple
> continues to support it
>
> I'd also note that, after the initial wave of users upgrading, there
> are very few users who upgrade from one major release to another
> before purchasing a new machine.
>
> This sentence also makes it sound like you want to drop support in a
> year. What does that mean practically? No longer working on 10.4 now
> or starting November 2009?
>
>> Remaining 10.4 users will still have access to the Gecko-1.9.1
>> products, which are fantastic.
>
> Until 6 months after we ship 1.9.next...
>
>> Also note... While it is Apple's policy that they never officially
>> drop support for any version of Mac OS X, they effectively only
>> support the release prior to the current one. By the time we would
>> ship without 10.4 support, Apple will have shipped 10.6 and
>> effectively stopped supporting 10.4. Officially supporting our product
>> on an operating system that does not receive security updates is not
>> desirable.
>
> Kind of... I agree that Apple doesn't officially drop support for any
> version of Mac OS X, however, they have offered updates for 10.3 after
> 10.5 shipped. Notably a security update on November 14, 2007 and a
> QuickTime update (to fix security bugs and add features) on January
> 15, 2008.
>
> See this and related documents:
> http://support.apple.com/kb/HT1222?viewlocale=en_US
>
> It's unclear what their methodologies are (unless you know something I
> don't), but my guess is that they base this on the user base of a
> given OS. We don't know what that means for 10.4 because we don't know
> how many 10.4 users there are.
>
>> === API support ===
>>
>> Apple is deprecating much of Carbon and some other APIs like ATSUI.
>> Finding replacements is much harder on 10.4 than it is on 10.5. Apple
>> wants to settle on the "Core..." APIs, at least for longer than they
>> have settled on any other APIs in the past few years. CoreText is one
>> API that we're particular interested in as it offers significant
>> performance advantages. CoreText is not available on 10.4. In
>> addition, 10.5 offers a more complete, faster, and less buggy
>> CoreGraphics API. I'll let Vlad go into the details of this if he
>> wants to. Of course 10.5 also has a better Cocoa API in general.
>
> Where do we want to use CoreText? Bug numbers would be preferred
> here... Do we know for sure that there's a performance advantage? How?
> I'd like to see numbers here, not just guesses based on what we think
> the API will do for us.
>
>> === 64-bit ===
>>
>> Developing a 64-bit version of Gecko for Mac OS X will be easier
>> without us having to support 10.4. 10.5 includes full 64-bit
>> application support and 10.4 does not. 10.6 will not only include
>> improved 64-bit support, but all signs indicate that it will run 64-
>> bit versions of applications by default. This means that an
>> application without a 64-bit binary in the universal bundle will
>> necessitate loading the 32-bit runtime libraries on 64-bit machines,
>> and I don't want Firefox to be the app that does that to people. 64-
>> bit is a priority for us even if our predictions about 10.6 turn out
>> not to be true - 64-bit is the future for Mac OS X desktop
>> applications.
>
> I think the line "10.5 includes full 64-bit application support" is a
> bit dubious, but prove me wrong. What about Carbon APIs? Aren't we
> still using some Carbon APIs? How will we move those over for 10.5
> users?
>
> 64-bit may be the future, but I haven't heard what it will do
> practically for users of Firefox. We need to switch, yes. But is the
> cost of switching now worth the benefit? And what *is* the benefit for
> end users?
>
>> === QA and Developer Resources ===
>>
>> Our support matrix is also about to get more complicated and dropping
>> support for 10.4 will simplify things. In 2009 we're going to have to
>> test:
>>
>> - 10.4 PPC
>> - 10.4 x86
>> - 10.5 PPC
>> - 10.5 x86
>> - 10.5 x86_64
>> - 10.6 PPC (unclear, we are assuming 10.6 will support PPC at this
>> point)
>> - 10.6 x86
>> - 10.6 x86_64
>
> Kind of... As I said above, it's not clear we need to move to 64-bit
> immediately (we don't have supported 64-bit builds on either Windows
> or Linux despite them both support it).
>
> Additionally, QA has already been through the testing cycle of 10.2,
> 10.3, 10.4 (PPC/Intel), and 10.5 (PPC/Intel). Adding one more OS isn't
> that much more additional work and with community support (since most
> of them are filing platform-specific bugs), we're at the same place we
> were before.
>
> This long list actually makes me think we shouldn't support 64-bit
> until later. It doesn't make me think we should drop 10.4 support.
>
>> 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 would
>> suffer from significantly increased code complexity, slower
>> development, and thinned QA coverage. Furthermore, WebKit is
>> aggressively taking advantage of new technologies and it will be hard
>> to keep up if we keep ourselves committed to 10.4 support.
>
> WebKit also supports 10.4... The Safari 4 beta does as well and that's
> currently unreleased (i.e., not released to the general public). Do we
> have any idea when they'll drop support? My hunch is no.
>
> Source:
> http://www.macrumors.com/2008/06/10/apple-seeds-safari-4-to-developers/
>
> --
>
> Overall, I'm not vehemently against dropping support for 10.4, I just
> don't think everything has been considered. Making this decision now,
> when over 40% of our users are on 10.4 doesn't seem like the right
> move. In the world of 80/20s, we'd still be supporting that 10.4.
>
> My gut says we should wait another cycle.
>
> -Sam
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Sent from my mobile device
Samuel Sidler
On Windows 2000, Windows XP, and Windows Vista, we officially support
only one architecture – x86 – which is what Josh meant. One day we may
support x86_64, but we don't yet. I can't speak to Windows Mobile, but
mobile in general is a different ball game.
-Sam
Robert O'Callahan
> === API support ===
>
> Apple is deprecating much of Carbon and some other APIs like ATSUI.
> Finding replacements is much harder on 10.4 than it is on 10.5. Apple
> wants to settle on the "Core..." APIs, at least for longer than they
> have settled on any other APIs in the past few years. CoreText is one
> API that we're particular interested in as it offers significant
> performance advantages. CoreText is not available on 10.4.
We won't be implementing Core Text for 1.9.2, unless a volunteer
contributor does it --- no MoCo person has signed up for it. It's even
possible that in the long run we'll ignore Core Text entirely and use
Harfbuzz on Mac instead (word is that Core Text's Opentype support is
not good and not likely to improve dramatically).
Rob
Axel Hecht
We do support Vista special APIs and functionality, including build
system hooks to disable those. And I bet there are runtime checks to
figure out if those fail or not.
I'd say that we at least support two versions of windows APIs.
Axel
Samuel Sidler
Again, Josh is talking about architectures here, not APIs.
For every Windows OS version we support, we modify our build config
ever so slightly, or, in some cases, quite a bit. We do the same for
Mac OS X versions. We even add support for specific features of OS X,
like we do on Windows. (The first one that comes to mind is Spotlight,
which we started supporting with Mac OS X 10.4 even though no previous
Mac OS X version had it.)
There's a fairly big difference between supporting additional
architectures and simply adding support for new APIs. That's
especially true on Mac OS X where we ship universal binaries with
support for two architectures.
-Sam
Robert Kaiser
> There's a fairly big difference between supporting additional
> architectures and simply adding support for new APIs. That's especially
> true on Mac OS X where we ship universal binaries with support for two
> architectures.
I haven't seen any post yet about obsoleting any architecture supported
on Mac though, only versions of OS X. I suppose obsoleting PPC will come
one day, but that's not what I have read about here.
Robert Kaiser
Samuel Sidler
> I haven't seen any post yet about obsoleting any architecture
> supported on Mac though, only versions of OS X. I suppose obsoleting
> PPC will come one day, but that's not what I have read about here.
No, this is a tangent based on your question about various Windows
versions being one architecture.
The argument is that we support two architectures (proposed-to-be
three soon) for Mac, in addition to two OS versions (potentially three
soon), while only supporting one architecture and three OS versions
for Windows.
-Sam
jos...@gmail.com
Mac OS X 10.5 was release in October 2007, so that is approximately
the last time something shipped with 10.4. Lets say Firefox 3.1 is
release February 2009 and Firefox 3.2 (made up name) is released
January 2010. That means support for Firefox 3.1 ends around July
2010. So, we will have supported the last machine that shipped with
10.4 for 2 years and 9 months. The majority of 10.4 machines will have
been supported for much longer than that.
By July 2010, it is very unlikely Apple will be releasing full
security updates for 10.4.
ss:
> 64-bit may be the future, but I haven't heard what it will do
> practically for users of Firefox. We need to switch, yes. But is the
> cost of switching now worth the benefit? And what *is* the benefit for
> end users?
...
> Kind of... As I said above, it's not clear we need to move to 64-bit
> immediately (we don't have supported 64-bit builds on either Windows
> or Linux despite them both support it).
We don't *need* to do anything depending on what sacrifices we're
willing to make. There are 2 major reasons I think we need to move
towards 64-bit aggressively.
First of all I think 10.6 users are going to want x86_64 versions of
applications since that is what everything else is going to be by
default on 10.6. That way we don't force them to load 32-bit libraries
which is faster and probably saves more memory than we lose going 64-
bit. Also it is likely that OS caching will be to our advantage since
all the applications will be using the same libraries if we're x86_64.
Secondly, and perhaps more importantly, x86_64 is the future no matter
what advantages or disadvantages we see and porting Gecko to x86_64 is
going to be *hard*. I've been working on it for a while and we have a
lot left to do. We have to rewrite major parts of Gecko and get
general cross-platform 64-bit support up to tier-1 quality (we have
never offically released a 64-bit version of Gecko for any OS). We
need to get going ASAP because we don't know how long this is going to
take and in the long run this is the architecture for which quality
matters most on Mac OS X.
As for comparing to Windows and Linux, neither OS has decided upon
aggressive 64-bit migration for the average user like Apple has.
Apples to oranges :)
ss:
> I think the line "10.5 includes full 64-bit application support" is a
> bit dubious, but prove me wrong. What about Carbon APIs? Aren't we
> still using some Carbon APIs? How will we move those over for 10.5
> users?
"Beginning with version 10.5, Mac OS X supports full-featured 64-bit
applications on G5-based and 64 bit-capable Intel Macintosh
computers."
ss:
> Where do we want to use CoreText? Bug numbers would be preferred
> here... Do we know for sure that there's a performance advantage? How?
> I'd like to see numbers here, not just guesses based on what we think
> the API will do for us.
...
roc:
> We won't be implementing Core Text for 1.9.2, unless a volunteer
> contributor does it --- no MoCo person has signed up for it. It's even
> possible that in the long run we'll ignore Core Text entirely and use
> Harfbuzz on Mac instead (word is that Core Text's Opentype support is
> not good and not likely to improve dramatically).
First of all, CoreText is almost certainly faster regardless of any
other issues it may or may not have. We can't be any more certain
until we actually implement a CoreText backend. Secondly it looks like
we're going to have to do something soon as much of ATSUI is going
away for 64-bit:
We're going to have to make this decision based on a large amount of
speculation, in part about how much pain not supporting 10.4 will
cause around July 2010 and in part about how much supporting 10.4
would hurt our other users and developers in the mean time (resources,
lower quality and fewer features). As a longtime Mac OS X user and
developer, I'm comfortable dropping 10.4 support after Gecko 1.9.1.
Axel Hecht
> To clear up math regarding support for the last 10.4 machines...
>
> Mac OS X 10.5 was release in October 2007, so that is approximately
> the last time something shipped with 10.4. Lets say Firefox 3.1 is
> release February 2009 and Firefox 3.2 (made up name) is released
> January 2010. That means support for Firefox 3.1 ends around July
> 2010. So, we will have supported the last machine that shipped with
> 10.4 for 2 years and 9 months. The majority of 10.4 machines will have
> been supported for much longer than that.
>
I understood the plan of 3.x to be that we ship more eagerly than every
year, but I haven't attended any gecko on-sites or calls lately, so that
might have become history already.
Axel
Vladimir Vukicevic
> To clear up math regarding support for the last 10.4 machines...
>
> Mac OS X 10.5 was release in October 2007, so that is approximately
> the last time something shipped with 10.4. Lets say Firefox 3.1 is
> release February 2009 and Firefox 3.2 (made up name) is released
> January 2010. That means support for Firefox 3.1 ends around July
> 2010. So, we will have supported the last machine that shipped with
> 10.4 for 2 years and 9 months. The majority of 10.4 machines will have
> been supported for much longer than that.
>
> By July 2010, it is very unlikely Apple will be releasing full
> security updates for 10.4.
FWIW, I agree -- 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.
>> We won't be implementing Core Text for 1.9.2, unless a volunteer
>> contributor does it --- no MoCo person has signed up for it. It's even
>> possible that in the long run we'll ignore Core Text entirely and use
>> Harfbuzz on Mac instead (word is that Core Text's Opentype support is
>> not good and not likely to improve dramatically).
>
> First of all, CoreText is almost certainly faster regardless of any
> other issues it may or may not have. We can't be any more certain
> until we actually implement a CoreText backend. Secondly it looks like
> we're going to have to do something soon as much of ATSUI is going
> away for 64-bit:
>
> http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/OtherAPIChanges/chapter_6_section_6.html
Yes, if we do go 64-bit, we'll have to implement CoreText or (hopefully
by then) be able to go the Harfbuzz route. 64-bit has additonal hidden
costs though, especially plugins -- I don't know what the ETA is for a
64-bit Flash, for example. If we can remain 32-bit through the next OSX
release, I'm guessing we will, just like we've remained 32-bit on win32
despite vista64 and friends.
- Vlad
jos...@gmail.com
> 64-bit has additonal hidden
> costs though, especially plugins -- I don't know what the ETA is for a
> 64-bit Flash, for example. If we can remain 32-bit through the next OSX
> release, I'm guessing we will, just like we've remained 32-bit on win32
> despite vista64 and friends.
There is a very good chance a 64-bit Flash plugin will ship with 10.6,
if it doesn't one will almost certainly follow soon after. Same goes
for Java (Mac OS X ships with Flash and Java plugins). As for plugin
support on our end, we are working on it already. We have a near-final
spec for the last thing we need:
Samuel Sidler
That's indeed true. I already commented about that to Josh. It's much
more likely we'll ship 3.next in September or October of 2009, giving
the most recent 10.4 machines less than two years of support.
-Sam
L. David Baron
> Secondly, and perhaps more importantly, x86_64 is the future no matter
> what advantages or disadvantages we see and porting Gecko to x86_64 is
> going to be *hard*. I've been working on it for a while and we have a
> lot left to do. We have to rewrite major parts of Gecko and get
> general cross-platform 64-bit support up to tier-1 quality (we have
> never offically released a 64-bit version of Gecko for any OS). We
> need to get going ASAP because we don't know how long this is going to
> take and in the long run this is the architecture for which quality
> matters most on Mac OS X.
>
> As for comparing to Windows and Linux, neither OS has decided upon
> aggressive 64-bit migration for the average user like Apple has.
> Apples to oranges :)
What are you referring to as problems with general cross-platform
64-bit support? I'm not aware of any such problems. Many Linux
distros ship 64-bit Firefox in their x86_64 distros, and a number of
Mozilla developers (including me) use 64-bit Linux Firefox as their
regular browser. The only practical issues I've run into as a
result are due to lack of 64-bit plugins.
And how is what Apple is doing more aggressive 64-bit migration than
what you get with the 64-bit versions of many Linux distros, other
than that they control the hardware and can therefore stop shipping
32-bit operating systems? (That said, on Fedora it's relatively
easy to install 32-bit apps and libraries alongside the 64-bit ones,
though. On Ubuntu, however, it's not, except for a small set of
"core" libraries.)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Samuel Sidler
> First of all I think 10.6 users are going to want x86_64 versions of
> applications since that is what everything else is going to be by
> default on 10.6. That way we don't force them to load 32-bit libraries
> which is faster and probably saves more memory than we lose going 64-
> bit. Also it is likely that OS caching will be to our advantage since
> all the applications will be using the same libraries if we're x86_64.
I'd assert that the majority of users won't know the difference
between 64-bit and 32-bit applications and, if they did (meaning, if
the difference was that obvious), Apple wouldn't ship an OS with 64-
bit on by default. The user experience would be horrible.
> Secondly, and perhaps more importantly, x86_64 is the future no matter
> what advantages or disadvantages we see and porting Gecko to x86_64 is
> going to be *hard*. I've been working on it for a while and we have a
> lot left to do. We have to rewrite major parts of Gecko and get
> general cross-platform 64-bit support up to tier-1 quality (we have
> never offically released a 64-bit version of Gecko for any OS). We
> need to get going ASAP because we don't know how long this is going to
> take and in the long run this is the architecture for which quality
> matters most on Mac OS X.
I have no doubt that the future is coming and it's paved with 64-bit
chips. I believe that's true on every platform, but can agree it's
more-true with Mac OS X. I disagree, however, that the work will be
any harder for Mac than other platforms, where we have community
builds available (Linux x86-64 even has a tinderbox running). A lot of
the assumptions needed to move to 64-bit have been made in many areas
of code.
Apple's website says that 64-bit doesn't mean faster applications on
Mac OS X. You argue that it will.
> As for comparing to Windows and Linux, neither OS has decided upon
> aggressive 64-bit migration for the average user like Apple has.
> Apples to oranges :)
I haven't seen Apple announce that the next OS will ship as 64-bit vs
simply supporting it.
> "Beginning with version 10.5, Mac OS X supports full-featured 64-bit
> applications on G5-based and 64 bit-capable Intel Macintosh
> computers."
>
> http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html
You didn't answer my question. But that link tells me no.
"Going forward, Apple plans to make new APIs 64-bit-compatible unless
otherwise noted. However, not all existing 32-bit APIs are supported
in 64-bit applications."
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/HighLevelAPIs/chapter_6_section_1.html#/
/apple_ref/doc/uid/TP40001064-CH224-SW6
Does that include APIs we use? Even if it doesn't, has Apple converted
all APIs we use on 10.5? That shouldn't be NDA-covered information.
> First of all, CoreText is almost certainly faster regardless of any
> other issues it may or may not have. We can't be any more certain
> until we actually implement a CoreText backend. Secondly it looks like
> we're going to have to do something soon as much of ATSUI is going
> away for 64-bit:
Yes, but I'd assert that moving to 64-bit shouldn't dictate when we
drop 10.4 support. I believe they're two issues that either you or I
tied together (I'm saying you based on your original post). "Should we
move to 64-bit soon?" is one question that should be answered, but
right now I'm interested in "Should we drop 10.4 support for the next
release?"
"64-bit is hard" isn't an answer to the latter, though it can
certainly be a small part of it.
That being said, you didn't answer the following questions I asked you
in my original reply:
> If our users haven't migrated and we still have, say, 1.5m users,
> will we change this decision? How much does Firefox usage on 10.4
> and its downward trend relate to when we'll make this switch?
...
> How does this compare with historical numbers? What's the uptake in
> our users from off of 10.3? How about off of 10.4? What kind of
> trends exist that we should be looking at to determine where usage
> will be in a year? (I'm guessing a year is about when a potential
> 3.next will ship)
...
> 64-bit may be the future, but I haven't heard what it will do
> practically for users of Firefox. We need to switch, yes. But is the
> cost of switching now worth the benefit? And what *is* the benefit
> for end users?
... (not a question, but a comment you should address)
> This long list actually makes me think we shouldn't support 64-bit
> until later. It doesn't make me think we should drop 10.4 support.
I'd specifically like answers to the first two questions.
Again, I don't think "64-bit is hard" is the right answer to "Should
we drop 10.4 support for the next release?" There should be many more
answers to that and I haven't heard them (I've only heard API support,
really; if we don't support 64-bit now, QA resources are a non-issue).
If it means delaying 64-bit to keep a good number of our users
supported (right now, 40%), I think we should.
-Sam
Samuel Sidler
> On Nov 10, 2008, at 3:12 PM, Axel Hecht wrote:
>
> That's indeed true. I already commented about that to Josh. It's
> much more likely we'll ship 3.next in September or October of 2009,
> giving the most recent 10.4 machines less than two years of support.
Err, excuse me. They'd be supported through April 2010 (at the latest)
which is two years and six months. Math is hard...
-Sam
Robert O'Callahan
> Yes, if we do go 64-bit, we'll have to implement CoreText or (hopefully
> by then) be able to go the Harfbuzz route.
I don't think Harfbuzz will be anywhere near ready for use in the time
frame Josh is talking about (the next release after 1.9.1). Especially
not for AAT --- as I understand it, Harfbuzz just doesn't support AAT
right now. In fact it might never make sense to implement AAT in
Harfbuzz, from our point of view; assuming Opentype is the future and
we don't want AAT on other platforms, it might well be less work to
just support CoreText for AAT alongside Harfbuzz for Opentype on Mac.
I think Josh has persuaded me that we will need to do Core Text, and
in that case we may as well start soon, or even now. We'll need to
land it early in the release cycle --- especially for a short release
cycle --- because this is fragile stuff that needs time to stabilize.
We can pretty easily have it as a build-time option alongside ATSUI
for as long as necessary. It shouldn't be a huge amount of work, and
we have people available to do it. I think we should do it, now.
Rob
L. David Baron
> I think Josh has persuaded me that we will need to do Core Text, and
> in that case we may as well start soon, or even now. We'll need to
> land it early in the release cycle --- especially for a short release
> cycle --- because this is fragile stuff that needs time to stabilize.
> We can pretty easily have it as a build-time option alongside ATSUI
> for as long as necessary. It shouldn't be a huge amount of work, and
> we have people available to do it. I think we should do it, now.
If it can be a build-time option alongside ATSUI, could that
build-time option be set different ways when building different
parts of a ppc32/x86-32/x86-64 universal binary?
We might not want to support that option for a long time, but it
might be reasonable for one release cycle, if necessary.
Robert O'Callahan
> On Monday 2008-11-10 17:25 -0800, Robert O'Callahan wrote:
>
> > I think Josh has persuaded me that we will need to do Core Text, and
> > in that case we may as well start soon, or even now. We'll need to
> > land it early in the release cycle --- especially for a short release
> > cycle --- because this is fragile stuff that needs time to stabilize.
> > We can pretty easily have it as a build-time option alongside ATSUI
> > for as long as necessary. It shouldn't be a huge amount of work, and
> > we have people available to do it. I think we should do it, now.
>
> If it can be a build-time option alongside ATSUI, could that
> build-time option be set different ways when building different
> parts of a ppc32/x86-32/x86-64 universal binary?
I would think so. It should only be necessary if we decide to support
10.4 and 64-bit in the same release.
Rob
jos...@gmail.com
> What are you referring to as problems with general cross-platform
> 64-bit support? I'm not aware of any such problems. Many Linux
> distros ship 64-bit Firefox in their x86_64 distros, and a number of
> Mozilla developers (including me) use 64-bit Linux Firefox as their
> regular browser. The only practical issues I've run into as a
> result are due to lack of 64-bit plugins.
Sounds like I might be wrong our general 64-bit build stability,
hopefully I am. My impression was that 64-bit Gecko was not heavily
used and that it wasn't as stable as 32-bit Gecko. In any case, we do
not release an official 64-bit Gecko binary for any platform and I
suspect that does make a difference in quality even if it isn't as big
as I imagined it to be. Could a 64-bit build make a talos/unittest run
go green?
> And how is what Apple is doing more aggressive 64-bit migration than
> what you get with the 64-bit versions of many Linux distros, other
> than that they control the hardware and can therefore stop shipping
> 32-bit operating systems? (That said, on Fedora it's relatively
> easy to install 32-bit apps and libraries alongside the 64-bit ones,
> though. On Ubuntu, however, it's not, except for a small set of
> "core" libraries.)
I think Apple's 64-bit push could be labeled as more aggressive
because they are going to get things like plugin support sooner and
like it or not, make life more difficult for 32-bit applications. Want
to avoid loading multiple versions of OS libraries? Make it 64-bit.
Looks like many users are going to be able to avoid 32-bit library
loads on 10.6. Want to take advantage of what the Apple optimization
teams are working on? All signs indicate that they are working on 64-
bit optimizations in their libraries and compilers, not 32-bit. Want
to write a prefpane for 10.6? Better make it 64-bit or you'll have to
relaunch the system preferences application. Want to write a device
driver? Better make it 64-bit or it won't work on the only version of
10.6 for newer machines. Only some of that applies to us but it all
applies to the question of how aggressive Apple is being about 64-bit.
Doesn't really matter much what we label it though.
I'll leave off with a paragraph from Apple and an Ars Technica's
review of Mac OS X 10.5's 64-bit support.
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. All over Cocoa, ints
have been replaced with NSIntegers. In all of the graphics APIs,
floats have been replaced with CGFloats."
L. David Baron
> On Nov 10, 6:47 pm, "L. David Baron" <dba...@dbaron.org> wrote:
> > What are you referring to as problems with general cross-platform
> > 64-bit support? I'm not aware of any such problems. Many Linux
> > distros ship 64-bit Firefox in their x86_64 distros, and a number of
> > Mozilla developers (including me) use 64-bit Linux Firefox as their
> > regular browser. The only practical issues I've run into as a
> > result are due to lack of 64-bit plugins.
>
> Sounds like I might be wrong our general 64-bit build stability,
> hopefully I am. My impression was that 64-bit Gecko was not heavily
> used and that it wasn't as stable as 32-bit Gecko. In any case, we do
> not release an official 64-bit Gecko binary for any platform and I
> suspect that does make a difference in quality even if it isn't as big
> as I imagined it to be. Could a 64-bit build make a talos/unittest run
> go green?
Yes. I've run full unit tests quite a few times. (I have fixed one
64-bit-specific reftest failure:
https://bugzilla.mozilla.org/show_bug.cgi?id=445626 . There's one
other reftest that fails reliably on my machine, and I think it's
related to fonts I have installed, but I haven't investigated
fully.)
And Linux distros probably ship a lot more Linux binaries than we
do. I'm not sure what their 64-bit vs. 32-bit usage numbers are,
though.
jos...@gmail.com
> I'd assert that the majority of users won't know the difference
> between 64-bit and 32-bit applications and, if they did (meaning, if
> the difference was that obvious), Apple wouldn't ship an OS with 64-
> bit on by default. The user experience would be horrible.
They probably don't know the difference between 32-bit and 64-bit apps
but they will be affected by having to load both runtimes. Activity
Monitor will easily allow that hit to be visualized. Whether they can
pick it out or not, we don't want to be responsible for taking up the
resources the OS needs to load for a 32-bit runtime.
Apple isn't shipping 64-bit by default because it is faster right now,
though that may or may not be a perk. They are doing it in part to
avoid loading two versions of each library, and if you have to pick
only one then 64-bit is the more capable - it can do everything 32-bit
can and more. Remember, a single 64-bit GUI app on a Mac OS X 10.5
forces a near-full 64-bit library load (Photoshop already wishes it
was that exception, that list is only going to get bigger).
Furthermore, picking only one allows them to focus their optimization
and support efforts. Lastly, 64-bit-by-default is an excuse for them
to leave old APIs in the dust, drop legacy baggage and start over with
things like the ABI.
> I disagree, however, that the work will be
> any harder for Mac than other platforms, where we have community
> builds available (Linux x86-64 even has a tinderbox running). A lot of
> the assumptions needed to move to 64-bit have been made in many areas
> of code.
Not true. Porting to 64-bit is in fact much harder on Mac OS X than it
is on Windows and Linux because as far as I know neither of those
platforms decided upon massive API deprecation for 64-bit. The hard
part is the platform-specific code where we have huge changes to make,
see what I wrote before. I never suggested that the cross-platform
code was the major problem, I only pointed out that it would be part
of the problem.
> Apple's website says that 64-bit doesn't mean faster applications on
> Mac OS X. You argue that it will.
No I didn't, you're misinterpreting. I only argued that the people
saying 64-bit will be slower have as little ground to stand on as
those who argue it will be faster by providing evidence for the faster
argument. I *did* say that particular APIs will be faster, but that
would be true for 32-bit as well. If we port to them for the sake of
64-bit, that is a perk. The speed of 64-bit vs. 32-bit in general was
never a core part of my argument.
That said, I do think 64-bit apps will run faster on Mac OS X
(especially on 10.6). I'm not willing to claim I know that will be
true in the short term for sure though.
> I haven't seen Apple announce that the next OS will ship as 64-bit vs
> simply supporting it.
It has not been officially announced but given what we know from
documentation, WWDC, and software seeds it is highly likely. The
evidence is overwhelmingly in favor of a 64-bit-by-default OS. The
only real remaining question is how many applications will be
exceptions, and it looks like none of the applications Apple provides
will be exceptions.
> > "Beginning with version 10.5, Mac OS X supports full-featured 64-bit
> > applications on G5-based and 64 bit-capable Intel Macintosh
> > computers."
>
> >http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorti...
>
> You didn't answer my question. But that link tells me no.
That doesn't make any sense. It clearly says 10.5 does support full-
featured 64-bit application right above what you wrote. You can run 64-
bit Xcode on 10.5 right now if you want. They didn't bring every API
over to 64-bit but they are never going to.
Josh Aas
bit Firefox on 10.5 so how fast 64-bit apps are on 10.5 or how buggy
the implementation is doesn't matter. 10.5 having full 64-bit GUI
support matters only because it makes development easier.
This discussion has largely revolved around 64-bit recently, so just
to refresh people's memory - the relevance of 64-bit is that dropping
10.4 makes going 64-bit much easier for us.
Samuel Sidler
> They probably don't know the difference between 32-bit and 64-bit apps
> but they will be affected by having to load both runtimes. Activity
> Monitor will easily allow that hit to be visualized. Whether they can
> pick it out or not, we don't want to be responsible for taking up the
> resources the OS needs to load for a 32-bit runtime.
This assumes a perfect world where no other 32-bit apps are on the
platform. That world won't exist for quite a while after 10.6 ships.
The transition from Classic to OS X was painful and took years. While
this isn't exactly the same (it's more like PPC to Intel), I imagine
Apple will make this much more seamless than that was (I'm thinking
along the lines of Rosetta).
The hit you're referring to may be visible in Activity Monitor, but to
most users will probably never be seen.
>>> "Beginning with version 10.5, Mac OS X supports full-featured 64-bit
>>> applications on G5-based and 64 bit-capable Intel Macintosh
>>> computers."
>>
>>> http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorti
>>> ...
>>
>> You didn't answer my question. But that link tells me no.
>
> That doesn't make any sense. It clearly says 10.5 does support full-
> featured 64-bit application right above what you wrote. You can run
> 64-
> bit Xcode on 10.5 right now if you want. They didn't bring every API
> over to 64-bit but they are never going to.
Erm... My question was: "What about Carbon APIs? Aren't we still using
some Carbon APIs? How will we move those over for 10.5 users?"
That's the question you didn't answer (along with a host of others
that I've already re-listed).
I still think the 64-bit discussion is a side one to dropping 10.4
support. Entering that discussion has led us astray from the real
topic. 64-bit might be related in some ways, but it (and APIs in
general) shouldn't be the only reasons we drop 10.4 support.
From a QA perspective:
I'm guessing here, but I imagine that adding 10.6 support (PPC and
x86) is less of a hit than adding 64-bit support on both 10.5 while
dropping 10.4. Adding new architectures is always more of a hit than
simply an upgraded OS. There are bugs that hid in the endian-ways of
PPC to x86. There will be similar issues with supporting a 64-bit OS
on Mac.
Additionally, we still have QA who use 10.4 as their main OS. We have
test coverage there and it's a known platform vs 64-bit which is an
unknown (on Mac), especially with the level of API changing you're
talking about. If 10.4 does get relegated to what 10.3/10.2 were (are,
really; Firefox 2 still lives), that'd still be fine. QA doesn't
actively use those OSes, but tests them on occasion.
There's also a QA hit when testing major updates to ensure we don't
serve certain updates to users of an unsupported OS. It's likely
minor, but it's not a scenario that's currently tested (for 10.4; we
tested it for 10.3). We'll have that QA hit eventually no matter what,
but it should be considered.
From a release-driver perspective:
I want to know what kind of numbers we're talking about. I asked it
originally and re-asked it before. Without numbers it's hard to make
decisions. Are we talking about 1m users being dropped in a year and a
half? 300k? We'll only have those answers after the data we have (of
our own users) on 10.5 uptake and the 10.3 downtake is analyzed.
I'd feel much more comfortable if you showed me a graph that estimated
we'd be down to 200k users by next year based on 10.5 uptake / 10.3
downtake (I'm using that word again even though it's not real). That'd
take a guess at when 10.6 would be released, but it'd certainly make
me feel comfortable about a decision to ditch 40% of our Mac users.
--
To put this all in perspective, when we decided to drop 10.3 support
(May/June 2007), 10.4 had been released for a two years (end of April,
2005) and we were hoping to ship Firefox 3 in February of 2008, giving
an end of life target of August 2008. That's 3 years, 4 months after
the release of 10.4. That didn't happen, of course. We shipped in June
2008 and are EOLing in December, 3 years, 8 months after the release
of 10.4.
When the 10.3 call was made, we had ~180k daily users on 10.3. (I'll
use daily averages from here on out.) Yes, we have more users than
that on 10.3 now! Amazing how our market share has grown. That
contrasted with ~900k 10.4 users and almost no 10.5 users since it had
yet to be released.
The math works out to ~16% of our users.
As of right now, 10.5 has been released for one year (as of last
month), we intend on shipping 3.next mid-late next year, giving an end
of life target for 3.1 of April 2010 (at the latest). That's 2 years,
six months after the release of 10.5.
Currently, we have ~40% of our users on 10.4 (from your original
stats), almost three times what we had on 10.3 when we decided to drop
support for it.
--
There's some numbers for you. I don't have 10.5 uptake numbers because
it's getting late. I'm sure you can get those just fine. The
"downtake" of 10.3 is actually an uptake, presumably because we're the
last browser to fully support their OS, but that's just a guess (and
yes, 10.2 usage has almost doubled in that time to ~35k users).
-Sam
Robert Kaiser
> Secondly, and perhaps more importantly, x86_64 is the future no matter
> what advantages or disadvantages we see and porting Gecko to x86_64 is
> going to be *hard*.
I don't understand this argument - we've had contrib builds for x86_64
on Linux even for 1.8.x, and I never heard of problems with those, so we
support Gecko itself at least build-wise and functionality-wise well
enough, it seems, we've just not been shipping it.
And I really wonder what the fuzz about two or three archictectures is
about when we support building and working version on Linux for more
than just three architecrues, and that with Linux being the
least-supported of all our tier-1 platforms (I know, only i686 Linux is
actually shipped).
Robert Kaiser
jos...@gmail.com
> josh...@gmail.com wrote:
> > Secondly, and perhaps more importantly, x86_64 is the future no matter
> > what advantages or disadvantages we see and porting Gecko to x86_64 is
> > going to be *hard*.
>
> I don't understand this argument - we've had contrib builds for x86_64
> on Linux even for 1.8.x, and I never heard of problems with those, so we
> support Gecko itself at least build-wise and functionality-wise well
> enough, it seems, we've just not been shipping it.
From a previous post of mine here:
jos...@gmail.com
> This assumes a perfect world where no other 32-bit apps are on the
> platform. That world won't exist for quite a while after 10.6 ships.
> The transition from Classic to OS X was painful and took years. While
> this isn't exactly the same (it's more like PPC to Intel), I imagine
> Apple will make this much more seamless than that was (I'm thinking
> along the lines of Rosetta).
I don't think it'll take that long. Apple started early and invested a
lot of effort into making 64-bit ports easy, it'll generally only be
hard for large apps with pre-Mac OS X codebases. I know quite a few
people that don't use Microsoft Word or Photoshop, the types of apps
that will be the exceptions for a while. Adobe has reportedly been
working on 64-bit Mac OS X apps for a while. It is true though that
for some time there will be popular exceptions.
> Erm... My question was: "What about Carbon APIs? Aren't we still using
> some Carbon APIs? How will we move those over for 10.5 users?"
10.5 has the 32-bit APIs we need to replace the Carbon we can't use in
64-bit. 10.4 does not. ATSUI/CoreText is the easiest example to give
because lots of people know what that is, but there are many other
smaller examples.
> From a QA perspective:
> I'm guessing here, but I imagine that adding 10.6 support (PPC and
> x86) is less of a hit than adding 64-bit support on both 10.5 while
> dropping 10.4. Adding new architectures is always more of a hit than
> simply an upgraded OS. There are bugs that hid in the endian-ways of
> PPC to x86. There will be similar issues with supporting a 64-bit OS
> on Mac.
Of course. Adding support for new things increases your bug exposure,
the question is what do we get out of it. I'm not worried about it
from a maintenance POV, especially given what we get out of the deal
(it is a long term investment, more-so than an OS version).
jos...@gmail.com
> I want to know what kind of numbers we're talking about. I asked it
> originally and re-asked it before. Without numbers it's hard to make
> decisions. Are we talking about 1m users being dropped in a year and a
> half? 300k? We'll only have those answers after the data we have (of
> our own users) on 10.5 uptake and the 10.3 downtake is analyzed.
Here's a calculation...
3.4 years after the release of 10.4 we have 0.3 million 10.3 users,
and we still support a browser they can use. We'd drop support for
10.4 users 2.75 years after the last copy of 10.4 shipped, 2.75/3.4 is
0.80, so we'd drop support for 10.4 users 20% faster - in large part
because we've been informed of *two* major intended architecture
changes since 10.4 shipped and Apple changes APIs aggressively
regardless of architectures. 0.3*1.2 is 0.36. Let's up that by 0.24
million, or 66%, for market share growth (generous). That's 0.6
million. We have around 200 million Firefox users now, lets say we
*don't increase that number at all in the next 1.5 years*. In that
scenario we'd be dropping support for 0.3% of users on the not-
upgrading end of things, people who aren't even getting full OS
security updates by that time. That's *one third of one percent* of
all of our users. Not a compelling number when we're talking about
tying ourselves to a particular OS version and set of APIs. That
number makes me want to invest more heavily in the future.
In Mac-only terms, that's 13% of all Mac users, out of 4.6 million in
total, assuming *we don't increase that number in the next 1.5 years
at all* (totally unreasonable, it is going to grow rapidly and those
users will be on 10.5 and 10.6). So well under 13% of Mac users
really, and again, only one third of one percent of all our users.
Robert Kaiser
> I don't think it'll take that long. Apple started early and invested a
> lot of effort into making 64-bit ports easy, it'll generally only be
> hard for large apps with pre-Mac OS X codebases.
So it's easy in general but you stated it's very hard for us because of
the system-specific APIs - and I thought those are what they invested in
to make it easy?
Robert Kaiser
Samuel Sidler
> On Nov 11, 3:36 am, Samuel Sidler <s...@mozilla.com> wrote:
>> From a release-driver perspective:
>> I want to know what kind of numbers we're talking about. I asked it
>> originally and re-asked it before. Without numbers it's hard to make
>> decisions. Are we talking about 1m users being dropped in a year
>> and a
>> half? 300k? We'll only have those answers after the data we have (of
>> our own users) on 10.5 uptake and the 10.3 downtake is analyzed.
>
> Here's a calculation...
A fairly incomplete one... see below.
> 3.4 years after the release of 10.4 we have 0.3 million 10.3 users,
> and we still support a browser they can use. We'd drop support for
> 10.4 users 2.75 years after the last copy of 10.4 shipped, 2.75/3.4 is
> 0.80, so we'd drop support for 10.4 users 20% faster - in large part
> because we've been informed of *two* major intended architecture
> changes since 10.4 shipped and Apple changes APIs aggressively
> regardless of architectures. 0.3*1.2 is 0.36. Let's up that by 0.24
> million, or 66%, for market share growth (generous). That's 0.6
> million. We have around 200 million Firefox users now, lets say we
> *don't increase that number at all in the next 1.5 years*. In that
> scenario we'd be dropping support for 0.3% of users on the not-
> upgrading end of things, people who aren't even getting full OS
> security updates by that time. That's *one third of one percent* of
> all of our users. Not a compelling number when we're talking about
> tying ourselves to a particular OS version and set of APIs. That
> number makes me want to invest more heavily in the future.
>
> In Mac-only terms, that's 13% of all Mac users, out of 4.6 million in
> total, assuming *we don't increase that number in the next 1.5 years
> at all* (totally unreasonable, it is going to grow rapidly and those
> users will be on 10.5 and 10.6). So well under 13% of Mac users
> really, and again, only one third of one percent of all our users.
I've asked Ken to comment here with his analysis when he gets a chance.
Taking the current number of 10.3 users and multiplying it out to
determine the 10.4 users isn't a valid way to determine future 10.4
marketshare. There's a reason I asked for trend lines to determine
estimated users in April 2010. Using 10.3 is wrong because it's a
different OS that was out for a different length of time, with
different features and had a different OS preceding it and a different
OS following it than 10.4. Looking for trends is valuable: using exact
numbers based on 10.3 isn't. (Or I could argue that we'll have double
the 10.4 users in a year and a half than we do now, just like what
happened to 10.3. But we know that's not true.)
For one, as I said before, there are more users on 10.4 now than there
were on 10.3 when we made the call to drop it. When we made that call,
10.5 hadn't shipped (and wasn't going to for four more months), but
10.4 had been out for over two years. Contrast that to now... 10.5 has
been out for a year and 10.6 is shipping... when? We don't know.
Sometime next year, maybe, possibly.
My point is that they're different OSes. I'll let Ken comment.
-Sam
Robert Kaiser
> That's 0.6 million. [...] That's *one third of one percent* of
> all of our users.
Right. It also happens to be about 150% of the most number of tracked
downloads any given SeaMonkey release ever had, for all platforms - just
as a fun fact to not lose our perspective ;-)
> In Mac-only terms, that's 13% of all Mac users
So more than 1 out of 10 Mac users is left out in the complete cold, a
percentage about in the same area as our market share in Asia or Africa.
Robert Kaiser
jos...@gmail.com
> My point is that they're different OSes. I'll let Ken comment.
Agreed. But not having the trend data, I attempted to make up for that
by plugging in a 66% increase in numbers for 10.4 over 10.3. That's
pretty generous. Also I factored in no growth in Firefox users or the
percentage of Mac users over the next 1.5 years. Also generous.
Its possible that I did some math incorrectly, if so please let me
know, but I think I generously made up for discrepancies between 10.3
and 10.4 users. Seems very likely that trend data would only decrease
the 10.4 users and percentages, and if we're OK with my higher count
then we'd definitely be OK with the lower number.
jos...@gmail.com
> So more than 1 out of 10 Mac users is left out in the complete cold, a
> percentage about in the same area as our market share in Asia or Africa.
That is a bad case, realistically probably a smaller number. And they
are on an OS that most likely isn't receiving regular security updates
at the time in question. The Asia/Africa analogy seems more
appropriately used as an indication of how few people use our product
in Asia and Africa.
Vladimir Vukicevic
It would probably be easier to make it a runtime option, which is better
in any case; we already have some central spots where we create
textruns/font groups.
- Vlad
Smaug
2006. As David said, plugins don't usually work but otherwise I
see no problems. I've filed few 64-bit related bugs, at least in
Spidermonkey. Fortunately they've been fixed pretty fast.
Mochitest/chrome/browser-chrome run just fine.
-Olli
Samuel Sidler
> I've asked Ken to comment here with his analysis when he gets a
> chance.
And he's forwarded me his analysis to post here.
On Nov 11, 2008, at 4:56 PM, Ken Kovash wrote:
> A few things:
>
> (1) The current ADU (blocklist) for 10.4 is 2.1 million (compared
> with 2.6 million for 10.5). Using our monthly multiple to find the
> approximate total user base, we probably have something in the
> ballpark of 6 million users on 10.4.
>
> (2) The change in usage among 10.4 users has not declined since one
> year ago. During this period, 10.5 was launched. Therefore, it
> seems reasonable to expect that the usage level from 10.4 users will
> remain relatively stable into late 2009.
>
> (3) It's more difficult to project future usage levels from 10.5
> users. Their growth rate has been approx. 100% during the past six
> month period. So, reaching an ADU of greater than 5 million in late
> 2009 would be a conservative lowerbound estimate. Beyond that, I'm
> not comfortable projecting an upperbound estimate.
>
> Ken
Some comments:
Given that it's safe to assume ~5m ADUs in a year of 10.5 (and
possibly of 10.5 and 10.6; 10.6 is an unknown here)...
That's 15m users to 6m 10.4 users, or 28.6% of total users in a year.
I'm sure that percentage will continue to decrease as time goes on
even as the total number of users remains stable.
Given what we saw for 10.3, there's a chance usage on 10.4 could even
go up, especially if Apple abandons Safari on the OS. There's
currently no signs of this happening (Safari 4 beta, as I said,
supports 10.3), but we'll find out soon.
Based on this data, I'm not sure we can ignore > 40% of our Mac users
now, when they'll still be > 25% of our Mac users a year from now.
I think we need to support 10.4 in Firefox 3.2 (or 3.next; whatever we
call it).
-Sam
Gen Kanai
While not directly germane to this particular thread, 12% of Firefox
usage is in Asia vs. less than 1% of the total number of Firefox users
in Africa.
http://blog.mozilla.com/metrics/2008/11/06/firefox-usage-and-europe/
I think lumping Asia and Africa together in this case is misinformed.
jos...@gmail.com
from anyone. Using your multiplier, what is the total number of
Firefox users out there today, is my 200 million number a reasonable
estimate? (I'd like the answer from Ken if possible)
A few notes:
- Percentage-wise that doesn't change much (we still have 20% fewer
10.4 users right now than we have 10.5 users) but the numbers are
multiplied, which does matter because we're talking about more people
regardless of the percentages.
- "Therefore, it seems reasonable to expect that the usage level from
10.4 users will remain relatively stable into late 2009." That may be
more true than I previously suspected, but all the 10.4 hardware out
there sunsets around the same time. When that happens, the numbers
should drop off much more quickly. Things will also drop off as other
apps abandon 10.4 support and 10.6 is released.
Ken's analysis provides the best argument I've heard so far against
dropping 10.4 support because of the total number of users.
On Nov 11, 2008, at 9:30 AM, Samuel Sidler wrote:
> Given what we saw for 10.3, there's a chance usage on 10.4 could even go up
That's not going to happen. Sam argued against himself well right
after he said that :)
> Based on this data, I'm not sure we can ignore > 40% of our Mac users
> now, when they'll still be > 25% of our Mac users a year from now.
Its more than a year from now that we're talking about - a couple more
months at least for 3.1, 10 months until 3.2, then 6 more months for
3.1 to EOL. That's 1.5 years.
I just don't believe that 10.4 users will constitute 25% of our users
in February or March of 2010.
Samuel Sidler
> Given that it's safe to assume ~5m ADUs in a year of 10.5 (and
> possibly of 10.5 and 10.6; 10.6 is an unknown here)...
What I mean to say is: "and possibly of a combined 10.5 and 10.6".
> Given what we saw for 10.3, there's a chance usage on 10.4 could
> even go up, especially if Apple abandons Safari on the OS. There's
> currently no signs of this happening (Safari 4 beta, as I said,
> supports 10.3), but we'll find out soon.
Err... "supports 10.4" not 10.3.
Proofreading helps, especially when you're on very little sleep...
*sigh*
-Sam
jos...@gmail.com
on dropping 10.4 support, I just wanted to get better arguments for
both sides and I think a lot of good info has come to light since I
first posted.
Samuel Sidler
>> Given what we saw for 10.3, there's a chance usage on 10.4 could
>> even go up
>
> That's not going to happen. Sam argued against himself well right
> after he said that :)
Yeah, I did. I argued with myself and won!
But at the same time, we don't know when Safari 4 final will ship and
we don't know how long it'll actually be supported. So it may matter
in, say, the second half of the first year. Or, more likely, the last
six months of the 1.5 years, if we want to try and estimate that far
ahead.
>> Based on this data, I'm not sure we can ignore > 40% of our Mac users
>> now, when they'll still be > 25% of our Mac users a year from now.
>
> Its more than a year from now that we're talking about - a couple more
> months at least for 3.1, 10 months until 3.2, then 6 more months for
> 3.1 to EOL. That's 1.5 years.
Yes, but we don't have estimates from Ken for 1.5 years from now, so I
was using what I had.
> I just don't believe that 10.4 users will constitute 25% of our users
> in February or March of 2010.
I wouldn't believe that either. I think that if we're dropping ~5%
ratio of 10.4:10.5 every four months, we'll be around 20% of Mac
users. (fwiw, using the math I was using earlier put it around 28%
after one year, but I didn't think getting that precise was useful.)
-Sam
Michael Connor
are well-understood by now. I'm going to assert a few things here:
* It is entirely unclear that significant migration from 10.4 will
occur by the time we ship 3.2
* There is not a compelling set of data which points to 64-bit support
being critical in any way to a 3.2 release, or even definitively in
scope.
* We don't have a crisp EOL date that Apple is giving us for 10.4
support, so we can't plan against that either.
* We do not have a definitive set of changes that will push us to
switch to 64-bit-safe APIs
Based on all of this, there just isn't a case that I can see as
acceptable from a product standpoint for dropping 10.4 support after
1.9.1. After 1.9.2 there is an entirely different set of math, but
then we're basically talking about dropping support in Q2 2010, and
that seems like an entirely reasonable timeframe.
Going beyond this specific case, i think we need to draft a real
policy on how we end support for platforms in general. I'll post a
followup on that subject shortly, since I've been thinking about that
since before we dropped Win9x and 10.3 support in Firefox 3.
-- Mike
On 11-Nov-08, at 9:40 PM, Samuel Sidler wrote:
> On Nov 11, 2008, at 6:20 PM, jos...@gmail.com wrote:
>>> Given what we saw for 10.3, there's a chance usage on 10.4 could
>>> even go up
>>
>> That's not going to happen. Sam argued against himself well right
>> after he said that :)
>
> Yeah, I did. I argued with myself and won!
>
> But at the same time, we don't know when Safari 4 final will ship
> and we don't know how long it'll actually be supported. So it may
> matter in, say, the second half of the first year. Or, more likely,
> the last six months of the 1.5 years, if we want to try and estimate
> that far ahead.
>
>>> Based on this data, I'm not sure we can ignore > 40% of our Mac
>>> users
>>> now, when they'll still be > 25% of our Mac users a year from now.
>>
>> Its more than a year from now that we're talking about - a couple
>> more
>> months at least for 3.1, 10 months until 3.2, then 6 more months for
>> 3.1 to EOL. That's 1.5 years.
>
> Yes, but we don't have estimates from Ken for 1.5 years from now, so
> I was using what I had.
>
>> I just don't believe that 10.4 users will constitute 25% of our users
>> in February or March of 2010.
>
> I wouldn't believe that either. I think that if we're dropping ~5%
> ratio of 10.4:10.5 every four months, we'll be around 20% of Mac
> users. (fwiw, using the math I was using earlier put it around 28%
> after one year, but I didn't think getting that precise was useful.)
>
> -Sam
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Mike Beltzner
costs in terms of what continuing support for 10.4 will mean for:
- what we can't do for 3.2
- what extra we must now do for 3.2
cheers,
mike
jos...@gmail.com
thread - Adobe has announced 64-bit Flash for Linux.
Damon Sicore
On Nov 15, 2008, at 12:00 PM, Michael Connor wrote:
> So, I've read through most of this now, and I think most of the
> points are well-understood by now. I'm going to assert a few things
> here:
>
> * It is entirely unclear that significant migration from 10.4 will
> occur by the time we ship 3.2
Josh, can we get a solid list of things we gotta do to continue
support of 10.4 if we do everything we want to do in 3.2? Then, if we
can't make it based on what we'd have to get done in time, what would
we have to drop from our plan if we continue supporting 10.4 in 3.2?
>
> * There is not a compelling set of data which points to 64-bit
> support being critical in any way to a 3.2 release, or even
> definitively in scope.
So far, the only two things that I've heard that would be close to
being critical are if we're forcing loading of a 32bit runtime that
triggers a massive startup delay and the other being if there are bugs
that would be fixed (i.e., not working around old bugs that will never
be fixed by Apple) if we used the new APIs. We need a list of what
those are.
Seems like, and I agree with Vlad earlier on in this thread, if we can
continue to support 32bit through the next OS X release, we'll
probably do so.
Mconnor did point out in a direct IM to me that we have to balance the
cost of a huge startup delay with cost of dropping support for a
particular version of the OS and losing users. Very valid point.
>
> * We don't have a crisp EOL date that Apple is giving us for 10.4
> support, so we can't plan against that either.
> * We do not have a definitive set of changes that will push us to
> switch to 64-bit-safe APIs
>
> Based on all of this, there just isn't a case that I can see as
> acceptable from a product standpoint for dropping 10.4 support after
> 1.9.1. After 1.9.2 there is an entirely different set of math, but
> then we're basically talking about dropping support in Q2 2010, and
> that seems like an entirely reasonable timeframe.
>
> Going beyond this specific case, i think we need to draft a real
> policy on how we end support for platforms in general. I'll post a
> followup on that subject shortly, since I've been thinking about
> that since before we dropped Win9x and 10.3 support in Firefox 3.
Seems like when we ask the question of when to drop support for XYZ,
we always find unique variables that force us into asking very
different questions each time, and this decision process is hard.
>
>
> -- Mike
>
> On 11-Nov-08, at 9:40 PM, Samuel Sidler wrote:
>
>> On Nov 11, 2008, at 6:20 PM, jos...@gmail.com wrote:
>>>> Given what we saw for 10.3, there's a chance usage on 10.4 could
>>>> even go up
>>>
>>> That's not going to happen. Sam argued against himself well right
>>> after he said that :)
>>
>> Yeah, I did. I argued with myself and won!
>>
>> But at the same time, we don't know when Safari 4 final will ship
>> and we don't know how long it'll actually be supported. So it may
>> matter in, say, the second half of the first year. Or, more likely,
>> the last six months of the 1.5 years, if we want to try and
>> estimate that far ahead.
>>
>>>> Based on this data, I'm not sure we can ignore > 40% of our Mac
>>>> users
>>>> now, when they'll still be > 25% of our Mac users a year from now.
>>>
>>> Its more than a year from now that we're talking about - a couple
>>> more
>>> months at least for 3.1, 10 months until 3.2, then 6 more months for
>>> 3.1 to EOL. That's 1.5 years.
>>
>> Yes, but we don't have estimates from Ken for 1.5 years from now,
>> so I was using what I had.
>>
>>> I just don't believe that 10.4 users will constitute 25% of our
>>> users
>>> in February or March of 2010.
>>
jos...@gmail.com
> > support being critical in any way to a 3.2 release, or even
> > definitively in scope.
>
> So far, the only two things that I've heard that would be close to
> being critical are if we're forcing loading of a 32bit runtime that
> triggers a massive startup delay and the other being if there are bugs
> that would be fixed (i.e., not working around old bugs that will never
> be fixed by Apple) if we used the new APIs. We need a list of what
> those are.
>
> Seems like, and I agree with Vlad earlier on in this thread, if we can
> continue to support 32bit through the next OS X release, we'll
> probably do so.
We are not dropping 32-bit for a while, that isn't even on the table
right now. We're only talking about 10.4 support.
The 32/64 bit stuff is about the fact that 10.4 support makes *adding*
a 64-bit binary more difficult and consumes more development
resources. I think we should be working on a 64-bit build ASAP because
that is what 10.6 users will want and we don't know exactly how long
it will take for us to get such a thing ready. We cannot leave 64-bit
build work until the day we realize users want it *now*. It is a lot
of work because of the APIs Apple dropped in their 64-bit OS.
> Mconnor did point out in a direct IM to me that we have to balance the
> cost of a huge startup delay with cost of dropping support for a
> particular version of the OS and losing users. Very valid point.
Just because people can't use the very latest version of Firefox
doesn't mean we're going to lose them. People on 10.4 can still use a
fully supported Firefox 3.1 until probably Q2 2010 - very much good
enough in my book. But remember - if we support 10.4 for Firefox 3.2
then we're going to support our product on 10.4 until Q2 2011. I don't
see us doing a good job of that, and I don't think it is worth the
time.
> > Based on all of this, there just isn't a case that I can see as
> > acceptable from a product standpoint for dropping 10.4 support after
> > 1.9.1. After 1.9.2 there is an entirely different set of math, but
> > then we're basically talking about dropping support in Q2 2010, and
> > that seems like an entirely reasonable timeframe.
That math is critically wrong. If we drop support for 10.4 in Firefox
3.2 then 10.4 users will lose support when we EOL Firefox 3.1 in Q2 of
2010 - 6 months after we release Firefox 3.2. So if you think dropping
support for 10.4 in Q2 2010 is "entirely reasonable" then you're
saying we should drop support in Firefox 3.2, current trunk.
jos...@gmail.com
> Josh, can we get a solid list of things we gotta do to continue
> support of 10.4 if we do everything we want to do in 3.2? Then, if we
> can't make it based on what we'd have to get done in time, what would
> we have to drop from our plan if we continue supporting 10.4 in 3.2?
Supporting 10.4 hinders us in at least the following areas:
- text support (we can't just use CoreText, we need to maintain ATSUI
for 10.4, we could try to ship both but ewww)
- graphics support (10.5+ APIs are off-limits or we use divergent
codepaths when possible)
- 64-bit support (10.4 does not support 64-bit GUI apps or many 10.5+
APIs necessary for 64-bit)
- developer tools (can't use gcc 4.2 to produce binaries for 10.4)
- widget support (10.5+ APIs are off-limits or we use divergent
codepaths when possible)
- QA (further straining of resources)
It is just not worth it when 10.4 users have a fully supported Firefox
3.1 until at least Q2 2010 regardless of what we decide about Firefox
3.2. Supporting 10.4 in Firefox 3.2 is not an efficient use of our
resources, especially when we have 10.6 and 64-bit to deal with now.