From time to time, it is necessary to make updates that affect a significant portion of, or the entire, codebase. For example, it might be necessary to restructure logging, or how strings are filtered in views. In the past, this has caused problems as developers are often working on multiple things concurrently, resulting in code written "the old way" getting committed after the commit introducing "the new way" is made, and then the "old way" continuing to spread as the wrong examples are copied and pasted.
In order to reduce the likelihood of this happening, Synchronous Code Update Checkpoints are being added with Registry 5. Synchronous Code Update Checkpoints work as follows:
- During normal feature development, if a developer identifies a change that needs to be applied to the entire codebase, they open a new JIRA and assign it to the next SCU release. No work starts on the change at this point. The developer responsible for overseeing this change is the assignee of the ticket.
- Once the final release of the current feature release is tagged, the Release Manager declares that it is time for the Synchronous Code Update work to begin.
- If there are no JIRAs in the next SCU release, development proceeds to the next general feature release.
- During the checkpoint, no commits may be made to develop except those associated with SCU issues. Multiple SCU issues can be worked on in parallel if they are not dependent on each other.
- The expectation here is that there is no "in flight" work, however, if a developer is already working on a new feature for the next release, then it is that developer's responsibility to ensure any code for the new feature is updated as needed for the SCU issue(s) being addressed before the new feature is committed to develop. The Release Manager may remind the developers of this requirements, but it is the developer's responsibility to adhere to it.
- Once the SCU issues are resolved, the SCU release is completed and work continues to the next feature release. The SCU release does not result in a public release.
Because these checkpoints operate as part of the develop branch, no changes are required to hotfix Branch Management.