What seems to be a reasonable step is to declare that Windows XP SP2
is the lowest supported version of Windows. Older versions will not
be blocked from working based on current plans, but are considered
What Unsupported Means:
* No tinderbox coverage
* No QA coverage
* No unit test or talos performance coverage
* Bugs only affecting these platforms will not be considered as
blocking any release 1.9.2 or later.
** We will accept fixes from interested parties that do not compromise
supported OS versions.
Please note that there may be future architectural changes (i.e.
process separation was brought up) which would make preserving any
compatibility impractical on these platforms. We will cross that
bridge when we come to it.
Since this proposes to keep support for WindowsXP SP2, it is much
better. I have a comment and then a question.
When it was announced that Mozilla would drop support for Windows98,
that decision was based at least partially on the fact that further
development of Gecko, Firefox, etc for PCs depended on using operating
system features that did not exist in Windows98. Thus, there was a
technical reason driving the decision. I would hope that similar
decisions in the future would also be similarly driven by technical
reasons and not by marketing efforts of the distributors of operating
Thus, if Mozilla products (and their clones such as SeaMonkey) can
*readily* continue future development with WindowsXP SP2, then such
development should not latch onto features only available in WindowsXP
SP3 or (worse) Vista. Yes, testing might be restricted to WindowsXP
SP3; but development should not purposely cause breakage under WindowsXP
SP2 unless there is a solid technical reason.
If a bug report is submitted by someone using a non-supported operating
system, is there a presumption within the Mozilla organization that the
operating system is the cause of the problem? Or is there at least a
preliminary analysis to see if maybe the problem does indeed exist in
Mozilla products under a supported operating system?
David E. Ross
Don't ask "Why is there road rage?" Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
I'd think so; that's what we do for 64-bit Linux, OS/2, 64-bit Windows.
All are just as "unsupported" as Win2k and WinXP(/SP1) will be with
In fact, most of the time the OS field is completely ignored in initial
triage. _If_ the person trying to reproduce can't do so, then we start
worrying about OS differences. This includes the supported OSes too: if
you file using Windows Vista and I'm trying to reproduce, I'll try to do
so on OS X 10.5. If that fails, I'll worry about whether the problem
might be Windows-specific. It being so is the rare case.
Reasonable and thanks for asking in the first place!
> What Unsupported Means:
> * No tinderbox coverage
> * No QA coverage
> * No unit test or talos performance coverage
> * Bugs only affecting these platforms will not be considered as
> blocking any release 1.9.2 or later.
> ** We will accept fixes from interested parties that do not compromise
> supported OS versions.
Does this also mean that we will not *actively* try to break W2K and
XP SP<2 *intentionally*??
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
> Mike Connor wrote on 15. Apr 2009:
>> What Unsupported Means:
>> * No tinderbox coverage
>> * No QA coverage
>> * No unit test or talos performance coverage
>> * Bugs only affecting these platforms will not be considered as
>> blocking any release 1.9.2 or later.
>> ** We will accept fixes from interested parties that do not
>> compromise supported OS versions.
> Does this also mean that we will not *actively* try to break W2K and
> XP SP<2 *intentionally*??
"Older versions will not be blocked from working based on current
plans, but are considered unsupported." So, yes.
That said, we should not rule out significant code cleanup that might be
had by removing workarounds, runtime checking, and other such pieces for
the older OS's. Code complexity is an added cost in these cases, and
it's an area that we're trying to actively improve in. If we're going
to call these OS's unsupported, then we may not want to pay that cost at
It sounds like we've actually got two effective versions here.
First, the oldest OS versions that we actively test and will fix bugs
for. Second, the most recent versions that we know will NOT work
(ex: because we now require APIs that they don't support).
Are we planning to keep track of which OS versions are known not to
work? I liked the idea floated earlier of our installer stopping (or
at least warning) users when they're trying to install a version that
isn't going to work on their OS. That said, it's extra work to keep
track of this, and I'm not in the position to make the call as to
whether it's worth it.
We already pretty much have this in practice, if not somewhere that is
crisply readable. It's really as simple as a table with a list of OS
versions vs. app versions, so the overhead isn't much.
I think I could write 'bot that could crank out stories like this, and
then we could sell them to news outlets. (New revenue stream for
> That said, we should not rule out significant code cleanup that might be
> had by removing workarounds, runtime checking, and other such pieces for
> the older OS's.
Yet, we're not even done with removing _already dead_ code like
"Bug 438331 - Remove WIN16 (support) code everywhere",
which should probably be followed by (at least a check for) W9x/ME then
(And I think XP_MAC "removal" is yet not completed either?)
So to remove W2K or WXP working code seems premature.