问题
If we have a source control branch that we use to stop features and bug test (including additional commits on this branch to fix said bugs), what should it be called?
Is "Release Candidate" appropriate?
My thoughts are that such a branch would be called "Release" and that using the word "candidate" implies it is immutable. You can have candidate 1 and candidate 2, but those specific candidates should never change; ie. candidate 1 wouldn't have any commits, that would modify it in any way.
Links or examples would be great, as the person I was discussing this with is very hard headed.
Related question: Is there any specification for promoting a release candidate? (covers how finished RC can be considered)
回答1:
It can still be considered as a final integration step (and in that, "not immutable"):
This is where you are still:
- integrating features approved to go into the next release.
- fixing bugs manifesting after integration test (SIT - System Integration Test, and UAT, User Acceptance Tests)
You can consider "RC" as being even more stable that I just described, but you could still fix show-stopper bugs.
In that sense, you wouldn't have "candidate 1" and "candidate 2" (simultaneously). RCs are usually sequential.
Then, a "Release" branch is for post-production (hot-fixes, and release maintenance).
It freezes the sate of the application when going into production, and uses that at a starting point to maintain what is into production.
In short:
- branches aren't immutable: they isolate a development effort in the development lifecycle.
You should be expected to add commits. In any branch. - Tags (or "label", or "baseline", or...) are immutable: they freeze a specific state of the code at a point in time.
来源：https://stackoverflow.com/questions/13753703/should-a-release-candidate-be-immutable