...
Each release, we create a release master branch followed by 3+ and release tags in various repositories. For example, in Nutmeg, we created these:
...
the open-release/nutmeg.master
...
branch for testing, followed by one tag for each point release: open-release/nutmeg.1, open-release/nutmeg.2, open-release/nutmeg.3.
...
We made those tags in these repos:
| Expand | ||
|---|---|---|
| ||
|
These branches and tags exist to help the Build-Test-Release working group orchestrate their help us coordinate testing, documentation, and bug fixes, and they . They are used as input to the community deployment tools, like Tutor. A However, a repository being tagged doesn’t necessarily mean it’s well-always mean its features are fully supported.More on that later.
To be tagged, a repository must be in the openedx GitHub organization. In order get a repository moved into the openedx organization, you can file an Axim request. It can then opt in to being tagged by including openedx-release: "<BRANCH-TO-RELEASE>" in their openedx.yaml file, where <BRANCH-TO-RELEASE> is typically set to master or main.
...
The top-level repositories inevitably depend on various dependent repositories (i.e., Open edX libraries). We do not put tags in our libraries, because those tags would often conflict with the library versions which . Instead, the top-level repositories specify in their requirements.txt and use setup.py and/or package-lock.json files to specify the which library versions they need. Different top-level repositories may need different versions of the same package.
More details are in OEP-10: Open edX Releases.
Features: Default, Supported, Experimental, and Unsupported
The tagged Tagged repositories include various features. Some features are enabled by default, whereas others need to be toggled on or configured.The release notes, roughly, mention four tiers of featuresThe exact definitions are still fuzzy, but the release notes generally group these features into four tiers:
1. Default features. These features are enabled out-of-the-box when someone installs Open edX using the supported community deployment tool (as of Quince, that’s Tutor). The Build-Test-Release WG treats these features as the highest priority for testing, bugfixing, and security.
2. Supported features. These features may be off by-default, but the community still tests them, tries to keep bug-free, and monitors their security. The community deployment tool usually makes it easy to turn these features on (for example, there may be an official Tutor plugin available).
3. Experimental features. These features are moving towards being Supported, but aren’t quite there yet. Site operators can turn them on in order to get a preview of what’s coming in future releases. Bug reports are appreciated, but may not be high priority.
4. Unsupported features. Tagged repositories sometimes include features that the community no longer supports, or never supported. This includes features which are deprecated but haven’t yet been removed. Site operators can turn these on, but should not expect bugfixes or security patches from the community
...