Moodle App Release Process
Six weeks before (Code freeze)
| # | Task | Responsible |
|---|---|---|
| 1. | Force an update of the local_moodlemobileapp plugin (as release candidate) with new strings in moodle.org/plugins (only for Moodle version 3.5). | Developer |
| 2. | Ask someone from sites or community team to review the new English strings. | Community or Sites team |
| 3. | 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. | Developer |
| 4. | Add the release notes in the release issue created (search for the release_notes tag). Ask someone from the documentation team to review the release notes. | Developer |
| 5. | Contact the marketing team announcing the new release and highlights. | Team Lead |
| 6. | Add new QA tests to the apps_test site. New QA tests should be labeled with qa_test_required, remove that label once they are added to the site. | Tester |
| 7. | 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 |
| 8. | Update npm dependencies in the main branch, and run npm audit to ensure all the dependencies are OK. Also check github vulnerabilities report. | Developer |
| 9. | Start testing | Tester |
The release day
| # | Task | Responsible |
|---|---|---|
| 1. | Set the right version number for the new Moodle LMS major release in the site.ts constant MOODLE_RELEASES. | Developer |
| 2. | Launch the internal release github workflow. | Developer |
| 3. | Do some testing with the production builds before sending the application to the stores (overall testing to see that nothing is broken):
| All the team |
| 4. | Send the applications to the stores for review. | Team Lead |
| 5. | Check TAG/Release have been created in github (moodlehq/moodleapp) with the version number. | Developer |
| 6. | Update the ci branch in the behat tests plugin (moodlehq/moodle-local_moodleappbehat) with the version number. | Developer |
| 7. | Open PR with release documentation updates (from moodlemobile/devdocs:app-docs to moodle/devdocs). | Developer |
| 8. | Mark the issue and the version as released in the tracker. | Team Lead |
| 9. | Update release notes. | Team Lead |
The following days
| # | Task | Responsible |
|---|---|---|
| 1. | Create an issue in the tracker for the next release, like: MOBILE-4270 | Developer |
| 2. | Social media announcements (Forum and Twitter). | All the team & Marketing team |
| 3. | Post in moodle.org/news. | Team Lead |
| 4. | 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 |
| 5. | Update branches and tags in all repositories (moodleapp, local_moodlemobileapp, local_moodleappbehat, etc.). | Developer |
| 6. | Prepare the repository for the next release:
| Developer |
| 7. | Check that the Docker image for the new version was successfully built. | Developer |
| 8. | Update of the local_moodlemobileapp plugin (as final release) in moodle.org/plugins. | Developer |
| 9. | Update of the local_moodleappbehat plugin (as final release) in moodle.org/plugins. | Developer |
| 10. | Check if the Android API level should be increased or not to use a recent one. | Developer |
| 11. | Review the new features/improvements specs/shaping documents to ensure that they clearly reflect the actual implementation of the feature. | All the team |
| 12. | Review that all the minor issues found during the QA testing have a related and triaged MOBILE issue in the tracker. | All the team |
| 13. | Make sure that tests are passing with all the supported versions in ci.moodle.org. | Developer |