Tentative high-level plans for 7.10.1

Daniel Trstenjak daniel.trstenjak at gmail.com
Mon Oct 6 10:46:25 UTC 2014

Hi Nicolas,

> So, if 1.4.x, 1.5.x, 1.6.x and 1.7.x are 'supported' versions, and some
> bug is found in 1.6.2, but turns out to be introduced in 1.5.1, we fix
> the bug in the 1.5 branch.
> Then, if the bugfix is important enough, we merge 1.4 in 1.5 (which can
> be a no-op), 1.5 in 1.6, and 1.6 into 1.7. As such, every version branch
> 'contains' all 'older' branches.

I don't like this practise, because you certainly don't want to always
incorprocate all commits of one release branch into an other.

Just think about a hackish bug fix needed to be added in a former
release, and in a newer release the problem has been solved in a
completely different way, and now, if you have bad luck, the former
release branch merges without conflicts into the new one, now getting
the hackish fix into the new release, which might be even harmful.

IMHO using cherry picking in this case is a lot better manageable.


More information about the ghc-devs mailing list