summaryrefslogtreecommitdiffstats
path: root/docs/python-support.md
Commit message (Collapse)AuthorAgeFilesLines
* python-support: adjust major versionsMike Frysinger2019-10-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The plan previously documented was <=1.13.x is Python 2 and >=1.14.x is Python 3. Other projects that migrated Python versions and drop support for older have tended to take a more drastic version jump to make it clearer to users. So lets adjust the plan to say <=1.x will support Python 2, and >=2.x will be Python 3-only. This also allows us to harmonize the repo launcher version. It is currently sitting at v1.26 and has been incremented independently of the repo version for the life of the project. While we might know these lower nuances, pretty much no one else does and it just leads to confusion: do I know version 1.26 or version 1.13.7? Or do I have both? What does that even mean? Once we update the major version to 2.0.0, we can also adjust the launcher script to 2.0.0, and then the launcher release process will be tied to a new repo release in general. Bug: https://crbug.com/gerrit/10418 Change-Id: Idb2257371a06e56d2923cf717345c028f49176a2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/240372 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* hooks: support external hooks running different Python versionMike Frysinger2019-07-271-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | As we convert repo to support Python 3, the version of Python that we use might not be the version that repo hooks users have written for. Since repo upgrades are not immediate, and not easily under direct control of end users (relative to the projects maintaining the hook code), allow hook authors to declare the version of Python that they want to use. Now repo will read the shebang from the hook script and compare it against the version of Python repo itself is running under. If they differ, we'll try to execute a separate instance of Python and have it load & execute the hook. If things are compatible, then we still use the inprocess execution logic that we have today. This allows repo hook users to upgrade on their own schedule (they could even upgrade to Python 3 ahead of us) without having to worry about their supported version being exactly in sync with repo's. Bug: https://crbug.com/gerrit/10418 Change-Id: I97c7c96b64fb2ee465c39b90e9bdcc76394a146a Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/228432 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* docs: document a Python 3 migration planMike Frysinger2019-02-011-0/+32
Bug: https://crbug.com/gerrit/10418 Change-Id: I72d82ce3a2d9af45d942bb10de82340110864ea5