If we follow the rule "retroactively", the possible branch point would be the last Cocoon release 2.1.4 as this would simplify much (no reverts necessary). Good patches could then be applied to 2.1 branch afterwards.
I prefer this way over an incompatible 2.1.5.
I have thought about it and I think we should branch from the 2.1.4 release. The main reason is the new 2.0 license. I guess we don't want to reapply all those changes.
Ah, yes, the relicensing. That's indeed a very important reason to go not back to 2.1.4. (But somewhere in your senctences a 'not' is missing :) )
I see no problem in branching now, remove the incompatible change and that's it. It should be easier to identify the incompatible changes (if there are more) than reapplying all the patches that we did since 2.1.4.
+1 That's of course much easier than doing the relicensing again.
And one question we should answer is: is there really a need for a 2.1.5 release?
Hmm, maybe not if we do the branch and revert the incompatible changes there as you wrote in the section above. But if we do this effort we can also release 2.1.5.
What about this? Branching 2.1 now, reverting incompatible changes, releasing 2.1.5, and continueing the development in the HEAD, releasing 2.2 after Cocoon Forms are refactored (that's the sugar for the upgrade :) ).
Joerg
