> I don't think that is the main source of complexity. > > The more difficult and fragile part of the workflows are: > * requiring commits to be cross-linked between branches > * and wanting changesets to be collapsed or rebased > (two operations that destroy and rewrite history).
I think there would be no technical problems with giving up the latter - it's just an expression of personal taste that the devguide says what it says. As for the former, I think it objectively improves the quality of the maintenance releases to have "managed backports", i.e. tracking that fixes are actually similar and correlated across branches. If you find this too complex to manage, one option would be to opt out of "backporting", i.e. apply changes only to the most recent branches. In many cases, the harm done by not backporting a fix is rather small - the bug may only affect only infrequent cases, or many users may be using a different branch, anyway. Others could then still backport the change if they consider it important (and do a subsequent "null merge" to properly link the backport). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com