Skip to main content

Moodle App Release Process

Six weeks before (Code freeze)

1.Create an issue in the tracker for the release, like: MOBILE-1248Integration Lead
2.Force an update of the local_moodlemobileapp plugin (as release candidate) with new strings in (only for Moodle version 3.5).Dev
3.Ask someone from sites or community team to review the new English strings.Community or Sites team
4.Announce in the moodle translation forums the new strings available. This will allow translators to add the new strings during the days prior to the release.Integration Lead
5.Add the release notes in the release issue created (search for the release_notes tag). Ask someone from the documentation team or Martin to review the release notes.Integration Lead
6.Contact the marketing team announcing the new release and highlights.Integration Lead
7.Add new QA tests to the "Testing cases" document. New QA tests should be labeled with qa_test_required. Remove that label once are added to the document.Tester
8.Run npm audit to ensure all the dependencies are OK and check github vulnerabilities report.Developer
9.Complete all TODOs related with the upcoming release, which are marked in code with a comment starting with @todo [version-number] (for example, before releasing 4.1 we'd search for comments starting with @todo [4.1])Developer
10.Freeze Cordova plugins and JavaScript libraries versions (node modules) in the main/version branch.Developer
11.Start testingTester

The release day

1.Fix the version name in config.xml, package.json and moodle.config.json (remove the -dev). Remember to update in config.xml the value of AppendUserAgent as well.Developer
2.Set the right version number for the new Moodle LMS major release in the site.js constant MOODLE_RELEASES.Developer
3.Launch the internal release github workflow.Integration Lead
4.Do some testing with the production builds before sending the application to the stores (overall testing to see that nothing is broken because of the branch merge done in step 2):
  • Correct definitive version name displayed (and commit)
  • AOT compiling worked
  • Language strings synchronised from
  • New language packs added
All the team
5.Send the applications to the stores for review.Integration Lead
6.Check TAG/Release have been created in github (moodlehq/moodleapp) with the version number.Integration Lead
7.Mark the issue and the version as released in the tracker.Integration Lead
8.Update release notes.Integration Lead

The following days

1.Social media announcements (Forum and Twitter).All the team & Marketing team
2.Post in Lead
3.Review the users and developers documentation (check that everything is in order). Review the docs_required and dev_docs_required_tags. Review the Mobile features wiki documentation.All the team
4.Only for major versions: Create version branch from main.Team Lead
5.Bump version numbers in the following files in the main/version branch: config.xml (version), package.json (version), moodle.config.json (versionname) appending a -dev to indicate that is a development version). Remember to update in config.xml the value of AppendUserAgent as well.Integration Lead
6.Unfreeze Cordova plugins and JavaScript libraries versions (node modules).Developer
7.Check that the Docker image for the new version was successfully built.Integration Lead
8.Update of the local_moodlemobileapp plugin (as final release) in
9.Update of the local_moodleappbehat plugin (as final release) in
10.Update the DEFAULT_LASTVERSION variable with the new major release on scripts/lang_functions.shDeveloper
11.Set the version number for the next Moodle LMS major release in the site.js constant MOODLE_RELEASES.Developer
12.Check if the Android API level should be increased or not to use a recent one.Developer
13.Review the new features/improvements specs/shaping documents to ensure that they clearly reflect the actual implementation of the feature.All the team
14.Review that all the minor issues found during the QA testing have a related and triaged MOBILE issue in the tracker.All the team

See also