TODO before final release:

• update list of contributors again

TODO items for the Shapely / PyGEOS merge:

• Merge packages into a single shapely package:
  • Merge the python source code of both packages into a single, minimal working shapely package -> Minimal working shapely package with pygeos code included #1237
  • Consolidate both strtree.py files -> API: update STRtree interface (merge shapely/pygeos features) #1251
• Continuous Integration:
  • Update and consolidate the github action workflow for testing -> CI: consolidate the build scripts and github actions tests workflow #1241
  • Update the github action workflow for wheel building / releasing -> CI: Fix the release workflows (GHA and travis CI) #1253
  • Ensure Travis CI is running (after moving to the shapely org?)
• Packaging:
  • Consolidate the setup.py parameters -> Consolidate setup.py metadata, remove old setup.py files #1376
  • Consolidate pyproject.toml and setup.cfg
  • Consolidate MANIFEST.in, ensure sdist/wheel creation is working -> Update MANIFEST.in to enable 'python -m build` to work #1249
  • Ensure versioneer is working and has a correct shapely 2.0.0.dev+.. version
• Tests
  • Move /tests to /shapely/tests -> #1257, #1275, ...
  • Combine / deduplicate tests where useful
• Documentation
  • Update docstrings
  • Merge the sphinx documentation sources -> DOC: Move pygeos doc pages into shapely docs #1377, DOC: restructure the combined docs + new theme #1402

Opening an issue to discuss the more practical aspects of the work on Shapely 2.0 (shapely/shapely-rfc#1). Changes needed in Shapely 1.8 (deprecations, etc) related to this are tracked in #932

The general route I am now trying out is to, iteratively, refactor the shapely code in-place. But @caspervdw mentioned at #782 also the option of starting "fresh" (for the code, not for the existing tests and things like that).

For both ways, the work can be done in a separate branch, and then using the normal PR workflow (with PRs targetting that branch). This branch has already been created: https://github.com/Toblerity/Shapely/tree/shapely-2.0 (but is already a bit behind master).
First question: how to keep this branch updated while master is still for 1.8? I would like to propose to initially rebase shapely-2.0 regularly on master. In an initial phase where there is still a lot of activity for 1.8 on master and only few people contribute to the shapely-2.0 branch, this seems easier / cleaner (there are eg also still some things to be merged in master on which we depend for shapely 2.0). Once the development focus shifts more to shapely-2.0, we can use the normal merging strategy already being used for the different branches right now. Does that sound good?
(I can volunteer to do the rebases / fix conflicts :-))

At some point we should probably move the source code of PyGEOS into Shapely (I would propose to do this in its entirety, and keeping its commit history (for proper attribution), and then clean-up / integrate in subsequent steps).
But initially, I am actually already testing some things (eg the Geometry subclasses) with using pygeos as an external package.

cc @sgillies @mwtoews @tomplex @caspervdw

Practical steps (to further fill in while we go, but to keep track of the items we already have/know):

• Remove the functionality deprecated in Shapely 1.8 (Deprecations for Shapely 1.8 #932)
  • Mutability -> PR [2.0] Remove mutability of geometries  #960
  • Adapter/proxy classes -> PR [2.0] Remove deprecated asShape / adapter classes #961
  • Ctypes / array interface
• Refactor the Geometry classes as subclasses of pygeos.Geometry -> Refactor Geometry classes to subclass the C extension type #983
• Remove shapely.geos.lgeos and its usage (use pygeos where needed instead) -> [2.0] Remove shapely.geos.lgeos ctypes interface to GEOS #1163
• Move all above changes into the main branch (-> Merge shapely-2.0 branch into main #1211)
• Move the source code of PyGEOS into Shapely (-> Demo of merging pygeos source into Shapely repo #1221)
• ...