Fork shapely-2.0 maintenance branch?

[mwtoews]

Checking with @shapely/shapely-team to see if now is an ideal time to split a maint-2.0 branch to maintain a shapely 2.0.x series?

This would allow new features like #1594 to appear in a future shapely 2.1 release series.

After a maintenance branch is split, I'm scheming to change a few things for shapely-2.1, such as:

• Drop Python 3.7, setting Python 3.8 as the minimum version
• Finally drop GEOS 3.6, possibly set the new minimum as GEOS 3.8 based on the same rational as before -- it is supported by the oldest Ubuntu LTS: libgeos-3.8.0

Also, does the shapely-2.0 branch need to exist anymore? I'm fine to clean up un-used / un-maintained branches like this.

[caspervdw]

Seems good to me! I just merged #1594 but branching before would be good indeed.

edit and totally onboard with dropping support for Python <3.8 and GEOS <3.8. We’ll also need to consider numpy for this.

[mwtoews]

Does numpy 1.17 seem appropriate as a new minimum version? It is the same version for focal, the oldest Ubuntu LTS -- see python3-numpy

[mwtoews]

I've created maint-2.0 for the new maintenance branch.

@sgillies could you add me as an admin for https://readthedocs.org/projects/shapely/ as I can set-up the multi-versions

@jorisvandenbossche unless I hear back on shapely-2.0 I'd like to remove the branch, since it may lead to confusion with maint-2.0

[sgillies]

Thanks @mwtoews ! RTD invite is on its way.

[jorisvandenbossche]

unless I hear back on shapely-2.0 I'd like to remove the branch, since it may lead to confusion with maint-2.0

Yes, the shapely-2.0 branch was fully merged into main (#1211), so removed it

[jorisvandenbossche]

Finally drop GEOS 3.6, possibly set the new minimum as GEOS 3.8 based on the same rational as before -- it is supported by the oldest Ubuntu LTS: libgeos-3.8.0

Relevant issue about this: #1000 (I recently mentioned there to raise the minimum to 3.7 (debian still has this), but personally I would also be fine with 3.8. But let's have that discussion over there)

[jorisvandenbossche]

Thanks @mwtoews for creating the maintenance branch and starting this discussion!

We also need to align on how we want to approach this branch. My proposal would be that, in general, every PR targets the main branch and is merged in the main branch first, and then if it's a specific fix we want for the bugfix release, we backport that commit to the maintenance branch (maint-2.0 at the moment).
So that means that in principle we don't do PRs directly to the maintenance branch (except for cases where the fix only applies to the branch, and not to main). Which should also avoid that maintenance branches ever need to be merged back into main, i.e. all actual development happens in main.

Does that sound OK?

[mwtoews]

Agree to most of this, that most development should go to main. There are only a few scenarios (like #1803) where there are maintenance branch PRs that don't apply to main. Is there any preferred approach to backporting? One is to manually cherry-pick one or more commits. Or using dedicated PRs with tools like https://github.com/marketplace/actions/backport-bot

[jorisvandenbossche]

There are only a few scenarios (like #1803) where there are maintenance branch PRs that don't apply to main.

Strictly speaking, for this specific example, that could actually also first be done on main if then #1802 was only done afterwards (since most of the changes in #1803 are also included in the other PR). Now, you already have the PRs, so that's also fine of course. And yes, fully agree that there will always be cases where we want to do PRs directly to the maintenance branch, and things like updating or fixing CI will be a typical example of this.

Is there any preferred approach to backporting? One is to manually cherry-pick one or more commits. Or using dedicated PRs with tools like https://github.com/marketplace/actions/backport-bot

For pandas we also use a bot (but another one, https://github.com/MeeseeksBox/MeeseeksDev), for geopandas I am typically the release manager for bug fix releases and there I manually backport commits. My experience is that doing it manually is fine for small projects (in pandas they already branch of the maintenance branch before the actual release, and there are a lot of commits being backported, so in that case automation is really important). So we can maybe start with cherry-picking manually, and can still move to a bot later on?

[mwtoews]

Manual cherry-picking of bug fix commits from main to relevant maint-* branches is perfectly fine with me too. I also recommend adding a comment to the parent PR like "Backported to maint-x.y with e86c420" (referencing the derived sha-1 for the cherry-picked commit).

[jorisvandenbossche]

Sounds good!

[sgillies]

I'd like to point out that merging upwards (https://git-scm.com/docs/gitworkflows#_merging_upwards) is the practice that got shapely to version 1.8. It's been fine for a project that isn't changing radically from version to version.

Is developing in main and backporting better? Can you explain why? Or is it that you are more used to the workflow of developing in main and backporting?