A few months prior to finalizing a new release of ACME, there will be a scientific "feature freeze" on a specified date.
Q. What does "scientific feature freeze" mean?
A. After the specified date, no code that introduces new scientific capabilities of the model can be introduced to the version being finalized. More specifically, a github "pull request" for completed code implementing the feature must be made before the feature freeze date/time.
Q. What if the pull request for my needed feature misses the deadline?
A. Then that feature will go in the release after the one being finalized.
Q. But what if it's is a really important feature that's supposed to be in that version?
A. The executive committee/Council retains the option of allowing exceptions, but exceptions will be few and should not be expected.
Q. What if the feature is "turned off" and doesn't change answers?
A. You can still add such features to the code base but first the testing must verify that the model is still bit-for-bit identical AND doesn't break the features that made it. If testing can not verify that, the feature does not go in to the release being finalized.
Q. What about code for new diagnostics or new data sets?
A. If the new code does not change answers, it can still be integrated to master before the release.
Q. What about bug fixes?
A. Of course if bugs are found in the frozen features during integration testing, fixes for those bugs can go in.
Q. I have a feature for the next version that will change answers and is ready to go. What do I do?
A. Wait until the maintenance branch has been established for the version being finalized. After that, master can accept answer or climate-changing code for future versions.
Q. What if I'm working on the build or test system?
A. The build/test system will have a different feature freeze date but the same rules apply.
Q. When can I no longer make any changes at all to the version being finalized?
A. That is the "code freeze" and will happen shortly before the release.