...
For background, see discussions at /wiki/spaces/SE/pages/3244039 page, /wiki/spaces/SE/pages/4718815, /wiki/spaces/SE/pages/5407073, and Council /wiki/spaces/CNCL/pages/18940320.
E3SM Version Names
E3SM will generally follow Semantic Versions 2.0.0 http://semver.org/spec/v2.0.0.html
In general, versions are labeled vMAJOR.MINOR.PATCH
First release of major versions are labeled as "vX.0.0".
First release of minor versions will be labeled as "vX.Y.0" with Y>0. (Note: Y is not limited to 1-9, so we can have v1.27.0 before v2.0.0)
Bug-fixes and other changes made to a released version vX.Y will be done on a "maint-X.Y" branch and tagged "vX.Y.Z" with Z>0.
Major version zero (v0.Y) is for initial development. Anything may change at any time.
We increment the numbers as follows:
- 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.
alpha, beta, rc
Prior to a vX.0 (X >1), E3SM may add alpha, beta and rc lables to versions as follows:
alpha = after all new features have been integrated. This version is run for a decade or more to look for instabilities not detected by short running development/integration testing. The first alpha tag is made after all the features from the feature freeze have been integrated to master. Additional alpha tags are made as needed.
beta = after alpha. Versions used for coupled tuning. The first beta tag is made after the coupled simulation group says alpha testing is finished.
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.
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
Development (aka Topic or Feature) Branch Names
What: A Development or "Topic" or "Feature" branch is made for any code changes needed for E3SM. This can be new development, bug fixes, merges from CESM, config changes or maintenance updates.
Who: Any E3SM developer can create a topic branch. They can be for development or also to temporarily mark a place in the code.
Convention: E3SM branch names will must have the form:
<Github username>/<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 SE team 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.
- Group leads may make additional conventions for <source code area or component> and <feature-description>.
...
tangq/cam/rrm
douglasjacobsen/clm/4import-v4.5.72
Permanent Branch Names: master, next, maint-x.y
...
next: A branch used for merging several topic branches for testing. Used to test several features at once. Is destroyed and re-created after the target group of features is merged to master. Also called an "Integration" branch. NEVER DO DEVELOPMENT OR SIMULATIONS FROM next.
maint-x.y: A branch started when a vX.Y release (internal or external) is made and used to provide updates and bug fixes for that release. A.k.a "release branch". After the maintenance branch is made, master can proceed to the next version.
...
What: E3SM will not tag every single merge into the E3SM master. E3SM will use tags on master to mark significant development stepsstages, and may coincide with versions where the Coupled Model and/or Performance teams simulations groups devote significant resources to evaluate climate or code performance.
...
- archive/cam/5.3.1
- archive/cam/5.3.2
- archive/cam/5.3.3
E3SM Version Names
E3SM will generally follow Semantic Versions 2.0.0 http://semver.org/spec/v2.0.0.html
In general, versions are labeled vMAJOR.MINOR.PATCH
First release of major versions are labeled as "vX.0.0".
First release of minor versions will be labeled as "vX.Y.0" with Y>0. (Note: Y is not limited to 1-9, so we can have v1.27.0 before v2.0.0)
Bug-fixes and other changes made to a released version vX.Y will be done on a "maint-X.Y" branch and tagged "vX.Y.Z" with Z>0.
Major version zero (v0.Y) is for initial development. Anything may change at any time.
We increment the numbers as follows:
- 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.
alpha, beta, rc
Prior to a vX.0 (X >1), E3SM may add alpha, beta and rc lables to versions as follows:
alpha = after all new features have been integrated. This version is run for a decade or more to look for instabilities not detected by short running development/integration testing. The first alpha tag is made after all the features from the feature freeze have been integrated to master. Additional alpha tags are made as needed.
beta = after alpha. Versions used for coupled tuning. The first beta tag is made after the coupled simulation group says alpha testing is finished.
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.
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
Figure: Tags and development graph
...