...
Update the pull request template in the master branch of edx/edx-platform to encourage developers to contribute bugfixes back to both the upcoming & next release branches (see for instance this PR).
🎁 Tagging a release or release candidate (Tagging Numbered Releases)
Releases are tags marking specific versions of all the repos. Take care with the steps to create and tag these. It's surprising, but you have to edit files to refer to the tags before you can create the tag.
There are two types of tagged releases:
the major release (zebrawood.1) and
the minor (“point”) releases (zebrawood.2, zebrawood.3, and sometimes zebrawood.4+).
The steps below apply to both major & minor releases, unless they say (major only).
1. Prepare for the tagging a week before it is scheduled….
1a. Schedule a release ceremony
Schedule a meeting for the day of release, including:
The release manager (you!)
At least one other Build-Test-Release WG member to check your work, take notes, etc.
If necessary, someone from Axim to grant permissions (see “Overview / Release Manager Permissions” section).
Anyone else who wants to listen in!
Ask someone from Axim to put it on the community working groups calendar.
1b. Double-check that the test plan is complete (major only)
Go to the Test Plan spreadsheet and check whether testing has been sufficiently completed (to the discretion of the release manager).
1c. Double-check that all known issues have been addressed
Prior to making a release (major, minor, or even a candidate), it is imperative that all known issues be fixed. You can check at the GitHub Project board with an appropriate filter such as “label:bug milestone:lilac.1”. Over time other labels or milestones may be incorporated, but just keep in mind that issues such as an uninstallable tag are unacceptable.
Search for open pull requests against the release branch. For example, for Nutmeg, we would search: https://github.com/pulls?q=is%3Aopen+is%3Apr+base%3Aopen-release%2Fnutmeg.master+archived%3Afalse.
1d. Create a wiki pages for release process notes
Create a child of this page for your own notes: Open edX Release Manager Notes
Example: Olive.1
2. Hold a release tagging ceremony
2a. Make a test branch (not a tag!)
To test the installation, but not yet mark the release, we'll make a test branch. The branch should use your personal prefix ("you/"), and be named for the release you are working on, but with an additional .n suffix. Don't use the full release name, or people will find the branch and think it is a release:
Info |
---|
Don’t create a tag for testing, because once it is pulled by other developers or processes, it becomes very hard to delete - specially on a busy repository such as edx-platform. |
Code Block |
---|
tag_release --doit --branch --skip-invalid --search-branch open-release/zebrawood.master --override-ref open-release/zebrawood.master you/test/z.1rc1.1 |
The .1 suffix is so that you can make a .2 if something needs to be fixed.
2b. Create release the Transifex project
Note |
---|
Translations after OEP-58 requires a new Transifex project for each named release. This will ensure the translations sources and code source stay in sync after Creating multiple projects isn’t ideal and can be revisited if it turns out to harm the Translator Experience. |
2b1 Double check the openedx-translations repository branch
Go to the https://github.com/openedx/openedx-translations repository and ensure it has the proper release branch e.g. you/test/z.1
.
2b2 Clone the openedx-translations Transifex project
After cutting the release e.g. zebrawood
a new Transifex project should be copied into a new project.
Create a new Transifex project: openedx-translations-zebrawood
Copy the resources from the old project (How to do that without ?)
2b3 Configure the GitHub Transifex App
This is a manual step:
...
Go to the Zebrawood Transifex project configuration settings
...
In the Integrations tab, click on the GitHub App integration “Manage” button
...
Click on the three dots ...
menu → the Settings button
Configure the project integrations settings from the main/master project (https://github.apps.transifex.com/projects/o:open-edx:p:openedx-translations/openedx/openedx-translations):
...
Select repo step:
Selected repository:
openedx/openedx-translations
Selected branch:
you/test/z.1
orrelease/zebrawood
...
Select files step:
Add a path to your YAML configuration file:
transifex.yml
...
Sync content step:
PULL CONTENT:
Fetch content automatically
PUSH CONTENT:
100% reviewed
How would you like Transifex to push translations to GitHub?
Create a Pull Request
andNo grouping
Add a prefix to the commit message:
chore:
...
6. Create the release Transifex project
Note |
---|
Translations after OEP-58 requires a new Transifex project for each named release. This will ensure the translations sources and code source stay in sync after Creating multiple projects isn’t ideal and can be revisited if it turns out to harm the Translator Experience. |
6a Double check the openedx-translations repository branch
Go to the https://github.com/openedx/openedx-translations repository and ensure it has the proper release branch e.g. open.release/zebrawood.master
.
6b Clone the openedx-translations Transifex project
Create a new Transifex project:
openedx-translations-zebrawood
.Add all the languages from the
openex-translatiosn
Transifex project.
6c Configure the GitHub Transifex App
This is a manual step:
Go to the Zebrawood Transifex project (
openedx-translations-zebrawood
) configuration settingsIn the Integrations tab, click on the GitHub App integration “Install” button
Allow the integration
Grant permission to your account
Grant permission to the
openedx/openedx-translations
repository
Continue the wizard to configure the project integrations to the following:
Select repo step:
Selected repository:
openedx/openedx-translations
Selected branch: Set it to the release branch e.g.
open.release/zebrawood.master
Select files step:
Set the path to your YAML configuration file to
transifex.yml
Sync content step:
PULL CONTENT:
Fetch content automatically
PUSH CONTENT:
100% reviewed
Set “How would you like Transifex to push translations to GitHub?” to
Create a Pull Request
andNo grouping
Add a prefix to the commit message:
chore:
Click on the Update Settings button
Wait for the sync to complete. It takes about an hour.
☑️ Ensure that all the resources has been added.
6d Update the Transifex resources names and tags
The GitHub Transifex App integeration puts an inconvenient names for resources like "translations..frontend-app-something..src-i18n-transifex-input--main"
instead of "frontend-app-something"
.
This can be fixed with the following command locally:
Code Block |
---|
git clone https://github.com/openedx/openedx-translations.git
cd openedx-translations
mkvirtualenv openedx-translations
pip install -r requirements/requirements.txt
# Dry run the name fix
make TRANSIFEX_PROJECT_SLUG='openedx-translations-zebrawood' fix_transifex_resource_names_dry_run
# If runs without errors, run the actual command:
make TRANSIFEX_PROJECT_SLUG='openedx-translations-zebrawood' fix_transifex_resource_names |
🎁 Tagging a release or release candidate (Tagging Numbered Releases)
Releases are tags marking specific versions of all the repos. Take care with the steps to create and tag these. It's surprising, but you have to edit files to refer to the tags before you can create the tag.
There are two types of tagged releases:
the major release (zebrawood.1) and
the minor (“point”) releases (zebrawood.2, zebrawood.3, and sometimes zebrawood.4+).
The steps below apply to both major & minor releases, unless they say (major only).
1. Prepare for the tagging a week before it is scheduled….
1a. Schedule a release ceremony
Schedule a meeting for the day of release, including:
The release manager (you!)
At least one other Build-Test-Release WG member to check your work, take notes, etc.
If necessary, someone from Axim to grant permissions (see “Overview / Release Manager Permissions” section).
Anyone else who wants to listen in!
Ask someone from Axim to put it on the community working groups calendar.
1b. Double-check that the test plan is complete (major only)
Go to the Test Plan spreadsheet and check whether testing has been sufficiently completed (to the discretion of the release manager).
1c. Double-check that all known issues have been addressed
Prior to making a release (major, minor, or even a candidate), it is imperative that all known issues be fixed. You can check at the GitHub Project board with an appropriate filter such as “label:bug milestone:lilac.1”. Over time other labels or milestones may be incorporated, but just keep in mind that issues such as an uninstallable tag are unacceptable.
Search for open pull requests against the release branch. For example, for Nutmeg, we would search: https://github.com/pulls?q=is%3Aopen+is%3Apr+base%3Aopen-release%2Fnutmeg.master+archived%3Afalse.
1d. Create a wiki pages for release process notes
Create a child of this page for your own notes: Open edX Release Manager Notes
Example: Olive.1
2. Hold a release tagging ceremony
2a. Make a test branch (not a tag!)
To test the installation, but not yet mark the release, we'll make a test branch. The branch should use your personal prefix ("you/"), and be named for the release you are working on, but with an additional .n suffix. Don't use the full release name, or people will find the branch and think it is a release:
Info |
---|
Don’t create a tag for testing, because once it is pulled by other developers or processes, it becomes very hard to delete - specially on a busy repository such as edx-platform. |
Code Block |
---|
tag_release --doit --branch --skip-invalid --search-branch open-release/zebrawood.master --override-ref open-release/zebrawood.master you/test/z.1rc1.1 |
The .1 suffix is so that you can make a .2 if something needs to be fixed.
2c. Test the release one last time
...