2025-06-12 Meeting notes

Node Upgrade

• After the conference we’ll evaluate whether we move to Node 22 or directly to Node 24. We’ll evaluate after the conference.

  • Max has a Candidate to help with coordination. Peter Kulko will help coordinate this upgrade.

  • @Peter Kulko will try to upgrade an MFE to using Node 24 so we can understand the dependencies and issues that we might run into that.

Python 3.12

• Likely to be ready for Ulmo but will be done after the Django Upgrade.

Breaking change process*

@Kyle McCormick

Prompt (from slack)

As we have more contributors from outside 2U and Axim working on the upgrades (yay! ), I feel that we're increasingly in need of some agreed-upon way to merge breaking changes to master that is simpler than the DEPR process.For example, Ram from WGU has a small upgrade PR here which follows the 4.2->5.2 upgrade requirement of combining the {DJANGO_FILE_, STATICFILES}_STORAGE into a single STORAGES dict. This is breaking change, because operators overriding the former will now need to override the latter. (We could theoretically have an expand phase here where we support both.

Django is not clear on what happens when you define both. Anyway.)Are we going to have Ram go through the whole DEPR process to in order merge this? Generalizing the problem, are we going to regularly ask first-time contributors who pick up these sort of upgrade tasks to go through the DEPR process any time that the task could affect an operator? To me, that feels like a huge amount of paperwork for a first contribution. I'm confident that we did not go through that process for every upgrade-related breaking change back at edX Inc.

I have ideas, but I'll leave it at that for now. Who would be interested in discussing this, and if you are, will you be at the Maintenance WG meeting and/or DEPR WG meetings tomorrow?

Robert’s slack response:

Some questions for us to consider:

1. Does the community want to support early deployers like MIT, current 2U, or future early deployers?

   1. Do we just need a short-term answer during some (voluntary or forced) transition phase to named releases?

2. The following questions are all basically saying the same thing in different ways, and assumes that early deployment (even if delayed by hours/days off a fork) is supported:

   1. Is it ok for the community to land as many breaking changes as they wish, that all would need to be handled in a short timeframe, and decided upon without input from the early deployers?

   2. Based on the constraints of being an early deployer, is some negotiation power required around breaking changes, or a requirement around an expand phase to provide breathing room for the breaking changes?

   3. Is an inform and schedule negotiation process required around breaking changes? Does the number of overall breaking changes in a tight timeframe affect the answer? How do we manage this number?

Note: I'm not trying to argue for or against the DEPR process specifically, but simply noting questions we can review to determine what would be the requirements of any process decision.

Discussion

Robert: Use an exclamation-point commit (eg feat!:) and notify about the change in #risky-changes

Feanil: It’s still useful to explain and warn about these changes. We don’t need the “approval” stage. Can we use a subset of the DEPR process for this?

Adolfo: This particularly applies to upgrades.

Robert: How much effort should we be willing to put in to allow for an “expand” (parallel support of old and new) phase?

Feanil’s idea - New ticket type - breaking change notice

• What’s the change?

• What do operators need to do?

• How long do they have? Default 1 month, less is OK

• immediately starts in Transition Unblocked

Jeremy: Are there other examples for this process?

Cypress maintenance restrictions

@Maksim Sokolskiy

• Cypress repo where Max doesn’t have access to secrets.

• Current actions point to stage.edx.org and relevant credentials.

• We want to run the cypress tests in other places, is that right?

  • Yes, we don’t want edx specific logic and settings in the openedx org repos.

• Teak sandbox is temporary using the master sandbox for testing makes most sense.

  • Master sandbox is not the same as our release sandbox

    • Master sandbox is not running Indigo

• Cypress Dashboard exists for the current repo maintained by edx.org, let’s come back to deciding if we want a community version of this one.
  
  

Ecommerce / Woocommerce maintenance

@Maksim Sokolskiy

• BTR - We don’t test ecommerce as a part of release testing.

  • We don’t have a finalized deprecation for ecommerce.

  • What’s the state of the new woocommerce integration?

• We curently tag the woocommerce plguin but don’t have it tested during the releases.

• ecommerce is not considered a part of the product core.

  • But we don’t want to prevent others from testing the items they care about.