Clarify Baseline High ESR clause

[dfabulich]

Fixes #4009

I went with "interpretation 1" from #4009, which I'm not 100% sure is correct, because there's a new Firefox ESR annually, so I can't imagine how a feature could get to 30 months and not be in a Firefox ESR.

[captainbrosset]

@jgraham could you please review?

[jgraham]

Suggested change

	For each feature definition in `web-features`, a wider-support status shall be conferred to the feature if the feature satisfies the following tests:
	The feature’s keystone date is on or before today’s date minus 30 months and the dates of the following long-term support releases:
	* Mozilla Firefox ESR, given by the release date for the latest x.0 release of Firefox ESR (or the previous x.0 release, when there are two active ESR releases).
	1. The feature’s keystone date is on or before today’s date minus 30 months.
	2. The feature's keystone date is on or before the release date for the latest x.0 release of Firefox ESR (or the previous x.0 release, when there are two active ESR releases).
	For each feature definition in `web-features`, a wider-support status shall be conferred to the feature if the feature satisfies the following tests:
	1. The feature’s keystone date is on or before today’s date minus 30 months.
	1. The feature's keystone date is on or before all of the dates listed below corresponding to browser long-term support releases:
	1. The x.0 release date of all currently supported Firefox ESR releases, excluding ESR 115.0.

[dfabulich]

Point of order: Do we need Baseline owners to change this??

The goal of my PR was to clarify the wording of the definition of Baseline without actually changing the meaning of the words.

Your proposal here changes the definition from supporting one or two Firefox ESR releases, to "all currently supported Firefox ESR releases," except for ESR 115 (the extra, extra extended ESR version).

I think changing the definition like this would require approval at our next Baseline owners meeting.

(Maybe my PR should, too? I dunno.)

As for the substance of your change…

"All supported except ESR 115" is coextensive with "latest and previous ESR, when there are two active"

https://whattrainisitnow.com/release/?version=esr just says that 140 is the latest ESR.

https://endoflife.date/firefox tells a clearer picture of the state of the releases over time.

• ESR 140 is the latest ESR, released Jun 2025
• ESR 128 is the ESR before that, released Jul 2024, EOL Sep 2025
• ESR 115 was released Jul 2023, and is still actively supported
  • ESR 115 would have been EOL in autumn 2024
  • Its lifetime has been extended to at least Aug 2026 ("We will re-evaluate this decision in July 2026")

For the sake of discussion, let's define the last ESR that Baseline High cares about as "the watermark for Baseline High" or "the watermark" for short.

• In Jul 2024, ESR 115 became the watermark, as ESR 128 was released.
• In autumn 2025, ESR 128 would have become the watermark, but ESR 115 was still active.
• In Jun 2025, ESR 128 became the watermark, as ESR 140 was released.
• In Sep 2025, ESR 140 became the watermark, as ESR 128 became EOL.

Our current "latest or previous" definition could be interpreted to means that ESR 115 is now the current watermark for Baseline, since ESR 115 is still supported. But the "previous ESR" in this definition refers to ESR 128, not the "earliest supported ESR when two are active."

And so, none of this has had any actual effect on the definition of Baseline. The 30-month watermark has been the true watermark the whole time.

I think we should stick with "latest or previous if two are active"

I think adopting a simple "all supported ESRs" definition would have committed us to making ESR 115 the watermark. To fix that, James added a special carve-out for ESR 115. If we adopted that language, we'd need to be sure to maintain the carve-out for other extra-extended ESRs in the future.

And so, I don't think we should actually adopt that phrasing. IMO, we can and should just stick with "latest or previous if two are active."

It's weird to make a "list" of ESR vendors with only one vendor in it

I guess having a "list" of one thing it makes it clearer that we would/could add other ESR releases to the list, e.g. from other vendors…?

But, if we did that, we'd have to convene a meeting of Baseline owners to change the definition. We could make it a list at that time (if that day ever comes, which I predict it won't in the next 10-20 years).

In conclusion, I like my version better than James' version, but, if we disagree, we should probably convene a Baseline owners meeting to confer.

[jgraham]

The current wording is:

Mozilla Firefox ESR, given by the release date for the latest x.0 release of Firefox ESR (or the previous x.0 release, when there are two active ESR releases).

My literal reading of that says

• When there is one ESR + 115 we have two active ESR releases, so it makes 115 the baseline defining release
• When there are two ESRs + 115 we have three active ESR releases, so we don't match the "there are two" clause, and it makes the latest ESR release the defining one for baseline

One can of course argue that "there are two" is supposed to be understood as "two or more", but in that case it's unclear which release the "previous" one is supposed to refer to.

It's very clear that the wording of the current definition didn't anticipate the current situation and is ambiguous in the face of it. I don't think your update changes anything here.

Moreover ESR 115 is now more than 30 months old, and therefore would define baseline (at least sometimes) per the rules. That isn't what we've actually applied and not what's intended.

We could try to find a rule that is unambiguous, or we could just treat 115 as an unanticipated special case and call it out. I think the latter is more straightforward.

[dfabulich]

I've force pushed a new draft that I think is unambiguous.

1. The feature’s keystone date is on or before today’s date minus 30 months.
2. The feature's keystone date is on or before the release date for the latest x.0 release of Firefox ESR.
3. The feature's keystone date is on or before the release date for the previous x.0 release of Firefox ESR, if it's currently active.

I think that would clearly exclude ESR 115, because it's not the previous x.0 release of Firefox ESR. 128 is the previous release, and it's not active. 115 is the previous active release, but that's not what the rule cares about; we only care about the previous release (128) and whether it's currently active.

[jgraham]

I think depending on people uniformly understanding "previous" to me "previous, even if it's not active and there is an active one that's older than the latest one" is optimistic. That is, you can argue that people shouldn't implicitly read "previous" as "previous active", but I think they will and we'll get the same kind of discussion again in the future.

[dfabulich]

How about this?

1. The feature’s keystone date is on or before today’s date minus 30 months.
2. The feature's keystone date is on or before the release date for the latest x.0 release of Firefox ESR.
3. The feature's keystone date is on or before the release date for the previous x.0 release of Firefox ESR, if it's currently active.

(This does not include active ESR releases before the previous x.0 release, even if the previous x.0 release is no longer active. For example, Firefox ESR 115 stayed active much longer than usual, but, after two subsequent ESR releases, the definition of Baseline would not rely on the release date of ESR 115, even if it's still active.)

I prefer this to adding "excluding ESR 115" in the actual definition of Baseline, because this definition doesn't commit us to update the definition whenever Firefox decides to create future extra-extended ESRs. In the future, we can read the parenthetical and say "Oh, I see. ESR 166 is just like ESR 115, so we don't have to use its release date now that ESR 191 is out."

[jgraham]

I prefer the opposite for basically the same reason :) I prefer a rule that requires us to handle special cases on a one-off basis rather than a rule that just assumes the handling will always be the same as we had for the first special case.

However I think the wording above does make it clear how the current situation is being handled.

Also regarding

I guess having a "list" of one thing it makes it clearer that we would/could add other ESR releases to the list, e.g. from other vendors…?
But, if we did that, we'd have to convene a meeting of Baseline owners to change the definition. We could make it a list at that time

Having a list makes it clearer that Firefox is only a special case insofar as it's the only browser that has currently asked to have specific consideration for users on older, still supported, versions. Whilst a decision would certainly be needed to add additional browser versions, making it clear that's an option is strictly an improvement to the structure, with no normative change.