Skip to content

Update barcalendar.py to reflect current openedx-supported versions - #730

Open
UsamaSadiq wants to merge 1 commit into
masterfrom
fix/support-window-calendar-data
Open

Update barcalendar.py to reflect current openedx-supported versions#730
UsamaSadiq wants to merge 1 commit into
masterfrom
fix/support-window-calendar-data

Conversation

@UsamaSadiq

Copy link
Copy Markdown
Member

Description

Closes #729.

Verified every hardcoded version and EOL date in barcalendar.py against the actual dependencies used by the current Open edX release (release/ulmo.3, tutor v21.0.8) and against each section's cited authoritative source (endoflife.date, elastic.co, djangoproject.com, nodejs Release schedule).

Changes:

  • Ubuntu: current version corrected from 24.04 to 22.04, matching the base image used by tutor v21.0.8. Uncommented the 22.04 nickname (Jammy Jellyfish) so it displays.
  • React: current version corrected from 16 to 18, matching the version used by all current Open edX MFEs (frontend-app-learning, frontend-app-authoring, etc.) at ulmo.3. edx-platform's own package.json still pins React 16 for legacy code, but MFEs are the actual current frontend stack.
  • MySQL: replaced the stale, already-EOL 9.4 innovation release with 9.7, the current LTS (released April 2026, EOL April 2034).
  • Elasticsearch: fixed the 9.0 end date, which was off by a year (2028-10 instead of the correct 2027-10 per elastic.co's published End of Maintenance Term).
  • Redis: replaced incorrect "indefinite" EOL markers for 8.0 and 8.2 with their actual known EOL dates, and fixed 8.2's start date, which incorrectly predated 8.0's start date. Repointed the section note from a Redis Enterprise lifecycle page to the correct OSS source (endoflife.date/redis).
  • Node: added the newly released Node 26 line as a forward-looking upgrade candidate.

Python (3.11) and Django (5.2) were checked and found to already be correct against the ulmo.3 release branch, no change needed there.

Testing

Ran barcalendar.py before and after the change. After the fix, the only remaining validation warnings are expected ones: future Django/Ubuntu releases not yet published on endoflife.date, and Elasticsearch entries that intentionally follow elastic.co's official major-version support policy rather than endoflife.date's per-minor-version tracking (documented in the code).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support Window Update

1 participant