...
Convention: E3SM branch names must on E3SM-Project/E3SM
must have the form:
<Github username>/<source code area or component>/<feature-description>
Branches on a developer's personal E3SM fork do not need to start with <Github username>
because this is clear from the fork name:
<source code area or component>/<feature-description>
- Use lower-case for everything. Even your username.
- Use hyphens instead of underscores.
- one name for the github username.
- This is the person in charge of the branch and not necessarily the only person working on it.
- The E3SM IG needs one person to act as point-of-contact to answer questions about the branch and take requests for merging.
- This is why github usernames should be close to the your real name.
- Only needed for branches directly on
E3SM-Project/E3SM
- Group leads may make additional conventions for <source code area or component> and <feature-description>.
...
- MAJOR version when significant new science capabilities are added and old ones possibly deleted.
- MINOR version when E3SM adds minor new science functionality in a backwards-compatible manner, and
- PATCH version when E3SM makes backwards-compatible bug fixes that do not change answers for supported cases.
alpha, beta, rc
Prior to a vX.0 (X >1), E3SM may add alpha, beta and rc lables to versions as follows:
...
rc = release candidate. Near-final version. Checked for documentation, portability. The first rc tag is made after the coupled simulation group determines beta testing is finished AND after a code freeze. Typically, the "rc" versions and released versions are nearly identical. We don't always use "rc" tags and will go from beta to a regular release tag.
Tag sequence before v1.0 may look like: v0.1, v0.2, .... v0.14, v0.15.....v1.0.0-alpha.1, v1.0.0-alpha.2, ...., v1.0.0-beta.1, v1.0.0-beta.2, ..., v1.0.0-rc.1,v1.0.0-rc.2, ...., v1.0.0
...