Forward-porting from release/ into develop

[Daniele Procida]

In case you missed it, our branch policy is now that we work mainly on the latest release branch (bug-fixes, small improvements). However, we also do some work on develop (new features, backward-incompatible changes).

<http://docs.django-cms.org/en/release-3.3.x/contributing/development-policies.html#branches>

Most pull requests that land in release *also* need to go to develop, of course, so need to be forward-ported.

Here's the problem: <https://github.com/divio/django-cms/compare/develop...release/3.3.x>.

That looks like a lot of commits that need to be merged into develop, but in fact nearly all of them are there already. They were cherry-picked into develop, which unfortunately changes the commit hashes, so Git doesn't actually know that they are there already.

The danger is that this is confusing and could lead to some commits being inadvertently left out of develop.

Merging the release/3.3.x branch into develop would tidy up that comparison, because a merge operation preserves the commit hashes. However, merging would merge all of those commits, including some that do things that should not find their way into develop - like <https://github.com/divio/django-cms/commit/3d67879973aac61be97ed240262421f35f5d8c4a>.

Is there a way to resolve this dilemma? Or, is there something about out our branching policy that means we're stuck with it?

Daniele

[Tim Graham]

I'd suggest that part of putting something on a stable/release branch should also involved cherry picking it to master if needed. That way nothing is forgotten and there's no huge, error-prone merge task to do at some later time by someone who's not familiar with all the patches involved.

Looks like this is the workflow that cpython adopted: https://mail.python.org/pipermail/python-dev/2017-February/147381.html