Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For more information, see /wiki/spaces/SE/pages/3244039 discussion page,  and discussions on  /wiki/spaces/SE/pages/4718815 and /wiki/spaces/SE/pages/5407073 pages.

ACME Version Names

ACME will generally follow Semantic Versions http://semver.org.

...

Minor versions will be labeled as "vX.Y" with Y>0. (Note: Y is not limited to 1-9, so we can have v0.27 before v1.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.

Development or Topic or Feature Branch Names

What: A Development or "Topic" or "Feature" branch is made for any code changes needed for ACME.  This can be new development, but bug fixes, merges from CESM, or maintenance updates.

Who: Any ACME developer can create a topic branch.  They can be for development or also to temporarily mark a place in the code.

...

douglasjacobsen/clm/4.5.72

Permanent Branch Names: master, next, maint-x.y

What:  The ACME source code will have permanent branches used for development and maintenance of the code.

...

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.

maint-x.y:  A branch started when a vX.Y release is made and used to provide updates and bug fixes for that release.  A "release branch".

...

Developers should avoid using "maint" in their topic branch names.

Tag Names on master and maint-x.y

Who:  Only integrators can create tags.  Users should never tag their development branches.   

What: ACME  ACME will not tag every single merge into the ACME master.  ACME will use tags only on master to mark major and minor releases and bugfix releases.significant development steps, and may coincide with versions where the Coupled Model and/or Performance teams devote significant resources to evaluate climate or code performance. 

The recommended method for users to mark specific points on the git master branch is for them to create a topic branch or fork.  These branches are equivalent to subversion style tags used in the CESM.    

Tag name examples

(tags in red have not yet been created as of  )

...

Every circle represents a commit of some code.

Archival Tag Names on Feature branches

Who:  Only integrators can create tags.  Users should never tag their development branches.   

What: Tags can also be used to archive versions of the code. This is the case where 

  1. exploratory runs were made (for climate or performance)
  2. where speculative code development was performed, not merged into master, but needs to be retained

(See /wiki/spaces/SE/pages/4718815 for discussion that articulated this use case.

Archival branches are similar to maintenance branches in that we want to keep them around to run again or to look through code modifications. However, maintenance branches are code releases that we actively maintain, which archival branches are not that formal will not be kept current.

Naming:

archive/<UserName>/<description>