Mac OS X 10.4 "Tiger" Support Post-1.9.1

[joshmoz]

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!

=== 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.
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Justin Dolske-2]

On 11/7/08 3:02 PM, joshmoz@... wrote:
> 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[joshmoz]

On Nov 7, 6:38 pm, Justin Dolske <dol...@...> wrote:

> 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.
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Robert Accettura]

joshmoz@... wrote:
> 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!
>
> -snip-
>  

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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Boris Zbarsky]

Robert Accettura wrote:
> 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Samuel Sidler]

On Nov 7, 2008, at 3:02 PM, joshmoz@... 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-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Samuel Sidler]

On Nov 7, 2008, at 6:36 PM, Boris Zbarsky wrote:

> 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Robert Kaiser]

joshmoz@... wrote:
> 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

I'm among the 10.3 users. I bought my 1.6ghz g5 in 2005 with the
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 <ss@...> wrote:

> On Nov 7, 2008, at 3:02 PM, joshmoz@... 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-planning@...
> https://lists.mozilla.org/listinfo/dev-planning
>

--
Sent from my mobile device
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Samuel Sidler]

On Nov 8, 2008, at 5:36 AM, Robert Kaiser wrote:

> joshmoz@... wrote:
>> 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?

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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Robert O'Callahan-2]

On Nov 8, 12:02 pm, josh...@... wrote:
> === 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Axel Hecht-2]

Samuel Sidler wrote:

> On Nov 8, 2008, at 5:36 AM, Robert Kaiser wrote:
>
>> joshmoz@... wrote:
>>> 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?
>
> 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.

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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Samuel Sidler]

On Nov 10, 2008, at 4:26 AM, Axel Hecht wrote:

> Samuel Sidler wrote:
>> On Nov 8, 2008, at 5:36 AM, Robert Kaiser wrote:
>>> joshmoz@... wrote:
>>>> 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?
>> 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.
>
> 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.

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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Robert Kaiser]

Samuel Sidler wrote:
> 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

[Samuel Sidler]

On Nov 10, 2008, at 7:34 AM, Robert Kaiser wrote:

> 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
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning