There’s been several discussions around where bug fix pull requests should target. There are two options. First option is targeting stable branch (1.2.x), and the other option is dev (1.x) branch. There are some pro/cons.
Merge to Stable branch (for example
- A bug fix goes into the Stable branch, for example
1.2.xduring sbt 1.2.x series.
- Patch releases are released in short window (around 2-week wait?).
1.2.xbranch is merged up to
1.xcontaining potentially multiple patches.
sbt and its submodules (io, util, lm, zinc) have been using this strategy.
- Pro: For the most part, the merge PRs are straight forward and it’s a semi-automatic process.
- Con: We have to do the “hey could you target 1.2.x instead” dance with contributors. GitHub does allow retarget but won’t work if they branched off of 1.x.
- Con: Maintainers have to periodically create “merge 1.2.x” pull request. If they don’t we could end up either missing bug fixes or merge conflict (coding on top of source that’s already changed).
Merge to Development branch (
- All pull requests regardless of bug fix or not go into the Development branch
- If the bug fix is worthy of patch release, either the maintainer or an advanced contributor can resend the patch against the stable branch.
- Otherwise, the changes are released in the next feature release (around 3 months wait?)
- Pro: Contributors are going to be less confused.
- Pro: 1.x would contain all commits as soon as they are available, which is good for integration testing and downstream project (Bloop).
- Con: The cherry picking process is annoying for the maintainers. This probably should go with policy on squashing commits to as few commits as possible per PR.
Zinc and the rest
Should the strategy be different for Zinc, or should we pick a consistent strategy across all sbt submodules?