Freezes and tags
Definitions
Before a freeze: science runs (to be done with a tagged release) are planned, features needed for those runs are identified, roadmaps are made to develop those features, people are tasked to develop the features. Developers will ensure new features work with existing master.
Feature freeze:
Date at which all work on writing new features for the next release is halted and "pull requests" are made to merge those features to master. Effort shifts towards integrating the completed features in to master and fixing bugs. A feature freeze improves stability by preventing the addition of new features which may not be complete or sufficiently tested and/or may have unexpected interactions; thus, a feature freeze helps improve the program's stability.
Configuration freeze:
Date at which all work to define the science configurations (compsets and resolutions) available from the new features is suspended, shifting the effort towards tuning the compsets for production runs. Changing science configurations that are being actively tuned may have disruptive effect on tuning, due to the introduction of new interactions between frozen features. Boundary and initial condition files are also frozen. Parameter values in code or scripts may continue to be changed as tuning requires.
Code freeze:
Date at which no changes whatsoever are permitted to a portion or the entirety of the program's source code. Particularly in large software systems, any change to the source code may have unintended consequences, potentially introducing new bugs; thus, a code freeze helps ensure that a portion of the program that is known to work correctly will continue to do so. Code freezes are often employed in the final stages of development, when a particular release or iteration has finished testing and production runs have begun, but may also be used to prevent changes to one portion of a program while another is undergoing development.
- Science code freeze: No changes at all to the science code including compsets and parameter values. May still have changes to script system (machine files, test lists) and internal documentation.
- Full code freeze: No changes whatsoever to any code.
Freeze schedule
Explanation of what is frozen when. Written for v1.0.0 but applicable to any ACME version. Focused on science code.
| Development stage | What can change or What happens | What cannot change |
|---|---|---|
| Before Feature Freeze | Any code that implements a new feature | NA |
| After feature freeze and during integration stage | Bug fixes. BFB, non-BFB or CC changes to completed features. Script system changes. | Code that implements new science features. |
| Feature integration completed | First alpha tag | |
After first alpha tag and before configuration freeze | Bug fixes, BFB changes. non-BFB or CC changes IF approved by coupled system tuning group. | Code that implements new science features. |
After configuration freeze and start of tuning. | BFB changes. Bug fixes and other changes IF approved by coupled system tuning group. | Code for compsets being tuned. |
| Alpha testing completed. Model does not blow up for all science configurations | First beta tag. | |
| After first beta tag. | BFB changes. Bug fixes in science code IF AND ONLY IF approved by coupled simulation group. | Anything else. |
| Beta testing completed | First release candidate (rc) tag. Science code freeze. | |
| Production runs with release candidates. | Only critical bugs found in production sims AND approved by coupled simulation group. BFB script changes. | Anything else. |
| release candidate after production runs | Nothing. Full code freeze. | Everything. |
| release | Make vX.0.0 tag. | |