Release plans: 2.22 and 3.0

[henryiii]

Description

I'd like to make a proposal for the versioning strategy and contents of the next few cibuildwheel versions. Here's the suggestion:

The next release (2.22) has the following features:

• feat: adding enable #2048 - But the default set of versions is the same if you don't set enable. We can warn if prerelease or free-threading standalone options are set.
• chore: add warning when running cibuildwheel with python<3.11 #2050
• feat: add manylinux armv7l #2052
• feat: support test-groups #2063

The following release of cibuildwheel I propose we call "3.0", with the following features (not a complete list):

• More enable groups, and removing the prerelease and free-threading standalone options.
• feat: use python3.11+ for cibuildwheel driver #1912
• New version of Split file utils into dedicated submodule #1873
• Add a test-sources configuration option. #2062
• Change the default build backend to build

After this point, we can shift our numbering up one, with major releases for adding/removing Pythons, minor release for features, and patch releases for bug fixes. This would allow the much-requested vX GHA tag to be something we can provide.

Thoughts?

[joerick]

The following release of cibuildwheel I propose we call "3.0", with the following features (not a complete list):

• More enable groups, and removing the prerelease and free-threading standalone options.
• feat: use SPEC 0 schedule for cibuildwheel #1912

This sounds good. It especially works well with the introduction of the enable option - we can make some braver decisions there, such as dropping pypy from defaults, or changing the policy on building non-eol pythons by default if we like.

• New version of Split file utils into dedicated submodule #1873

Ah yes. I'm happy to take a pass at this if you haven't started already?

After this point, we can shift our numbering up one, with major releases for adding/removing Pythons, minor release for features, and patch releases for bug fixes. This would allow the much-requested vX GHA tag to be something we can provide.

Here, I'm less sure. Personally, I see the compatibility part of our versioning system to be related to the package and configuration, not so much the Python versions that we build. That's my logic behind not being too worried about bumping major when dropping an old version. I see the specific versions of wheels produced more of an side-effect of the time that version of cibuildwheel was released, not part of the API contract.

Having said all that, we don't follow Semantic versioning anyway, so maybe the specific definition of compatibility is moot.

The bigger point is - do users need to care? When I see a package I use bump major, I'll assume there might be some work I need to do to update - read the release notes, maybe update the config files as a result. But I don't think that applies for Python addition/removal updates. The Python additions require no work (assuming you've already made the package compatible during the beta phase), and the removals are probably so old as to not be of interest (we're still building 3.6!).

Put another way - should we be requiring a major version bump to move an old version of PyPy into the pypy-eol enable group? I think it's better to reserve the major bump for circumstances where packagers need to pay attention, outside of the usual churn of interpreter versions.

[joerick]

An aside, but since we're talking about a new major version, a couple things we should consider-

• Changing the default build-frontend to build - the only reason we're still on pip is inertia, in my opinion. Of course, the build method of doing sdist->wheel builds will break some users, who might have to switch back to pip, but I think build is a better default these days.
• Adding delvewheel as a default option for repair-wheel-command on Windows. (cc @adang1345)

I think I'd be in favour of both, but curious of opinions.

[henryiii]

the build method of doing sdist->wheel builds

That won't affect us at all, since we build with --wheel, which is a direct build, like pip's. If we made SDists, they'd collide.

Yes, more changes is fine, I was just listing what I could quickly think of.

It might be a good time to finally switch the docs to show the TOML option first, with the envvar as second tab.

As for moving to more SemVer-like versioning, it was mostly to get people to stop complaining about a lack of a vX tag. Not required if we'd rather say with the current versioning scheme.

[joerick]

That won't affect us at all, since we build with --wheel, which is a direct build, like pip's. If we made SDists, they'd collide.

Oh, I didn't know that. That's good. So build's wheel builds are 'in-tree', like pip's then?

It might be a good time to finally switch the docs to show the TOML option first, with the envvar as second tab.

Good call.

As for moving to more SemVer-like versioning, it was mostly to get people to stop complaining about a lack of a vX tag. Not required if we'd rather say with the current versioning scheme.

My opinion on this has shifted lately... I think we should just relent and make a vX tag anyway. I think that while it's probably not a good idea for serious, professional packages, there are plenty of hobbyists who just want wheel builds and don't particularly care about the details. That seems valid to me. The number of side-projects I have that get constant dependabot spam for CVEs I don't care about, the dependabot fatigue is real.

[adang1345]

Regarding adding a delvewheel default repair command, I'm not sure. I have noticed that current cibuildwheel users frequently use the --add-path option to tell delvewheel where to find DLL dependencies during the repair process, and the path used is different for each project. It may be better to require the user to manually set the repair command and just put an example command in the documentation such as delvewheel repair -w {dest_dir} {wheel}.

[henryiii]

So build's wheel builds are 'in-tree', like pip's then?

pipx build is not in-tree, it builds a wheel from an SDist. But pipx build --wheel is, as there's no SDist built.

[mayeut]

I added #2052 to the list for 2.22 per #1912 (comment) comment

[EwoutH]

3.0 might also be an oppertunity to bump the default manylinux version:

• feat: move default manylinux build to manylinux_2_28 #1988

[joerick]

Would it make sense to create a v3 branch we can start merging these new features into?

[henryiii]

Aren't we just about ready to release 2.22? We just have #2048 and #2052 left. Then we can move forward with main being version 3, and make a v2 branch for back ports.

[henryiii]

IMO, 2.22 is ready.