It would be good to have a policy for this, but on the practical side I don't foresee another major version upgrade (like v2 -> v3) happening for quite some time.

Vue and its related libraries follow a slower pace of "major" releases than say React and related libraries do.

For now I think it would be okay to say that we'll follow 3.X minor upgrades and 3.X.x patch upgrades as needed (addition of new features, security fixes, etc); for any future major upgrade (4.X, meaning breaking API change) I think we can evaluate as a special case.

I refer to Vue above but this policy would likely also work fine for all related official projects (Vuex, Vue-test-utils, Vue-Router, etc). In the React ecosystem things are a lot more de-centralized and many different third-party plugins will iterate at different rates; in the Vue world there is a smaller number of key projects but they tend to change at a similar pace.

Regarding IE11 (and other non-ES6-capable browsers), I just want to say that downgrading Vue back to v2 is not very feasible at this point. Codex is written from the ground up in Vue 3 (which is not compatible with IE11), and the migration process from v2 -> v3 is underway for all other Vue.js features in MediaWiki.

The decision to allow new JS features to drop support for legacy browsers like IE11 came out of a Product department discussion in late 2020/early 2021 (led by Jon Katz), and was re-affirmed in last summer's Developer Summit (see T286947; this was one of the key questions we set out to resolve). More documentation from this part of the summit discussion can be found here.

We can continue to support users of legacy browsers by providing solid non-JS interfaces as a fallback, wherever a team deems necessary. This approach also has other benefits (some users of modern browsers also disable JS for various reasons, and providing a no-JS UI can be helpful for performance and SEO). I think this is compatible with what the Growth team is considering – ensure core functionality is available without JS, but some enhancements or non-critical features may require it.

Commons MediaSearch (one of the first big Vue features) uses a similar approach – there is a robust no-JS version of the UI that legacy browsers and no-JS users will get; everyone else gets the Vue-based experience.

I do hope we can refine (and document) this policy – it will help us resolve some related questions like T289208.

Staff members working on MediaWiki should have a clear policy on legacy browser support and what experiences must be supported on legacy browsers. Having this policy will help us maintain our commitment to using modern software and allow us teams plan ahead for migrations so they are minimally disruptive. Like the support policy for PHP, the browser support policy should not require an RFC for browser deprecation decisions.

Mediawiki's official browser support policy is described here: https://www.mediawiki.org/wiki/Compatibility#Browsers. There is also a long-standing Phabricator task around raising the requirement for all JS support (new or existing features, Vue-based or not, etc) to ES6 – see T178356. I see the work that has been done so far around Vue 3, ES6 support, and IE11 deprecation (for new, JS intensive features) as a step in this direction.

I think it would be good to connect the various conversations around when/where to use Vue, what baseline level of JS MediaWiki needs to support, what level of no-JS fallbacks should exist for various features, etc.

I think it would be good to connect the various conversations around when/where to use Vue, what baseline level of JS MediaWiki needs to support, what level of no-JS fallbacks should exist for various features, etc.

Agreed. Here's how I've been approaching the tasks so far -

This task will address the baseline level of JS MediaWiki needs to support and what level of no-JS fallbacks should exist for various features. Those questions are framework-agnostic and we can base decisions on where/when to use Vue around the answers.

I created T302351 (Proposal for Vue.js/Codex Development & Performance Guidelines) to capture Vue-specific blockers, which was meant to clone and track the output of T289208 (Develop and document a proposal for when to use Vue/Codex.). I'm now realizing that the titles aren't aligned, but they're both getting at guidelines for frontend development concerns as they relate to Vue specifically so I think it would make sense to use the Foundation ticket title for both.

Both of these open questions around browser support and Vue development are blockers for design system adoption and are equally important. I think we can parallel path on both of them. I'd like to complete both of these proposals in Q4.

For this browser support task, next steps I'm going to take are:

• Searching for data on IE11 usage and user impact (I'm going to request access to Turnilo and talk to the analytics team, let me know if you have other suggestions)
• Connect with Growth team to learn what "basic activities" outside of reading/editing are currently supported by legacy browsers
• Connect with other teams to understand what features they currently deem necessary to have in IE11, and why, and cross-check with data

Requests being considered for the next version of MediaWiki (this week):

• Remove IE9 & IE10 from basic support T293298
• Bump basic and modern supported Android browsers to v5 T290815
• Move Firefox 27-38 from Basic support to Unknown support T297313

Design Systems, Readers Web, Growth, and Analytics teams are in support of moving forward with the request to stop MediaWiki testing/support for IE9, IE10, Firefox 27-38, and Android browsers below v5. We will move forward with pushing this through for the next version of MediaWiki.

Key factors in the decision:

• Downgrading IE9, IE10, and Firefox 27-38 from Basic Support to Unknown Support has no bearing on peoples' ability to use Visual Editor, considering VE is already not available to those versions
• Only 0.000025% of edit attempts in the past year were from users with Android browsers below v5 (roughly 300 out of 16 million) so loss of this functionality is not significant and benefits of improved performance vastly outweigh the cost
• The analytics team affirmed that recent increases in traffic from IE9, IE10, and Firefox 27-38 starting on Feb 23, 2022 is coming from bots

From the task description:

Related OKRs: P-PPL

I'd like to know what this means. I did a quoted search for "P-PPL" on mediawiki.org as well as Meta-Wiki, which yielded no results.

In T298268#7786950, @STHart wrote:

[…] loss of this functionality is not significant and benefits of improved performance vastly outweigh the cost

Which performance improvement is this referring to? I could not find mention of it within this task or its comments.

An update based on feedback from downgrading IE9/10 support:

Since there are many downstream MediaWiki stakeholders for this decision-making process, the "source of truth" for this process might be better placed on a MediaWiki page for decisions/logs that people can subscribe to. It could live adjacent to https://www.mediawiki.org/wiki/Compatibility. Will update the task (including OKRs, will grab a proper description - that one is a catch-all for Platform work - thanks @Aklapper)

In T298268#7885127, @STHart wrote:

An update based on feedback from downgrading IE9/10 support:

Since there are many downstream MediaWiki stakeholders for this decision-making process, the "source of truth" for this process might be better placed on a MediaWiki page for decisions/logs that people can subscribe to. It could live adjacent to https://www.mediawiki.org/wiki/Compatibility. Will update the task (including OKRs, will grab a proper description - that one is a catch-all for Platform work - thanks @Aklapper)

Yup, that's https://www.mediawiki.org/wiki/Template:Compatibility_browser right now and I think it should continue as such.