-
Notifications
You must be signed in to change notification settings - Fork 300
Deciding which branch to target
Our current process aims to release frequently, with incremental changes as bug-fixes to the current version, but having a new minor version every few months. A couple of minor versions later, we release a major version that will disrupt compatibility, but we will continue supporting the previous version until all issues have been resolved in the new release.
We follow the standard major.minor.point-seq release numbering, with even numbers being the public releases. For example, 3.8.2 is the current release, with 3.10 being the next and 4.0 being the next major. We also use branches named candidate-MAJOR.MINOR.x as being the ones that receive the commits for the releases already spawned off the master branch, and the master branch for whatever is too far away. So, to which branch should you target your fix/feature?
If the work you're doing is for the current/next release, target it to the candidate branch of its release version. So, if it is release 3.8.2, target to candidate-3.8.x and that will get either cherry-picked or merged back to the release branch candidate-3.8.2.
All commits to candidate branches will be merged into newer candidate branches (ex: 3.8.x -> 3.10.x) and then to master. So, don't worry that your commit will be available in all subsequent releases as well.
Future work can be targeted to master, as long as none of it will be dependent, or hinder features needed in the spawned releases.
For instance, if you need to do a refactoring of part of the code, and it's going to take too long (many months), you can target master, but you should be wary that all features and bug-fixes on that area of the code will probably conflict when merging candidate branches to master, or worse, the merge will work, but the code will silently fail at run-time.
Since refactoring shouldn't change the behaviour of the code (in theory), it's best to always target it to the current candidate and make sure in each step, the code is consistent and independent. This may mean that it will not walk directly towards the best way to do (ie. you could commit not-so-good code), but as long as the stream of patches are going towards the right goal, it should be fine.