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.
Feature freeze:
in which all work on adding new features for the next release is halted, shifting the effort towards integrating features, fixing bugs and tuning the simulation. The addition of new features may have a disruptive effect on other parts of the program, due both to the introduction of new, untested source code or resources and to interactions with other features; thus, a feature freeze helps improve the program's stability.
Configuration freeze:
In 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:
In 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 features that made it in. 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, non-BFB or CC changes to features that made it in. Script system changes. | Code that implements new science features. |
After configuration freeze and start of tuning. | BFB changes. Bug fixes 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. BFB script changes. | Anything else. |
| release candidate after production runs | Nothing. Full code freeze. | Everything. |
| release | Make vX.0.0 tag. | |