Develop a long-term backport strategy
Leading up to the merge with Python 3.8, I maintained a cpython
branch in this repo and I would merge changes from master into that branch and use that to port the changes into CPython. Since then, there have been some changes, some contributed to CPython and others contributed here. Up to the 0.18 release, all of the changes here seem to have been ported to CPython also, and only this change was contributed only to CPython (amended in 3c389f53), but even just that change means that the porting instructions are no longer valid. Moreover, the fact that some portions of importlib_metadata.__init__.py
get ported to importlib.metadata
and other portions go to importlib._bootstrap_external.py
(and git has lost that ancestry), the cpython
branch is becoming more of an impediment than a help.
At one point, I'd imagined that after the merge that CPython would become authoritative and importlib_metadata
would be simply a backport... but that approach would preclude previewing/validating behavior in the more mutable external package first.
So I open this ticket for comment. What's the best strategy to keep these two codebases in sync? I can think of a few options:
- Require all changes to be applied only to CPython first and backport here.
- Require all changes to be applied to the backport first and forward-port to CPython.
- Allow the two codebases to diverge but try to keep them in sync as needed.
Other things to consider:
- Remove documentation from backport (rely entirely on docs in CPython).
How does the importlib_resources
project inform this (or vice-versa)?