Prepping for a 2.2 release

[jmwright]

In this discussion the decision was made to start doing releases every 6 months (January and June). This is the first in that release schedule. The schedule of 6 months is arbitrary. CadQuery has a growing number of projects that rely on it, and they are often requesting newer releases to build on. Our last release was nearly 2 years ago.

Once this is merged I will publish the release to PyPI and then change __init__.py and setup.py back to use development version numbers.

[codecov]

Codecov Report

Merging #1245 (ecc41be) into master (4a79b31) will decrease coverage by 0.20%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #1245      +/-   ##
==========================================
- Coverage   94.09%   93.89%   -0.20%     
==========================================
  Files          26       26              
  Lines        5432     5549     +117     
  Branches      919      945      +26     
==========================================
+ Hits         5111     5210      +99     
- Misses        190      201      +11     
- Partials      131      138       +7     

Impacted Files	Coverage Δ
cadquery/__init__.py	87.50% <0.00%> (ø)
cadquery/cqgi.py	81.99% <0.00%> (+1.25%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jmwright]

@adam-urbanczyk @lorenzncode Please take a look when you get a chance. codecov is failing, but it shows 0.00%.

[lorenzncode]

What to do with the Sketch solver? After testing last year, that is one area that I think may not be ready to be released.

[jmwright]

We've gone two years without a release because there was always something that wasn't quite ready, and because we have a pretty good rolling release system in place. I would propose to do the January-June release schedule, but be flexible as well.

If something in core is seriously broken, then we won't force a release, but we need to try to fix it so we can hit somewhere in the one month release window. Also, if there need to be supplemental releases, we can do those. So if we release 2.0.0 and find a major bug, we could do a 2.0.1 release. Also, if the Sketch solver is perfected before the June release, we might want to do the 2.3.0 release early. It's not a hard schedule, mainly just something to keep us moving forward with releases. It gives projects something to pin to and to use when reporting errors. Something like "I'm running 2.0.0 installed from PyPi."

[jmwright]

I have started documenting the release process here to make it easier for other devs to help with it. We might be able to automate parts of it at some point as well.

[adam-urbanczyk]

Yeah, I'd mark the 2D solver and 2D hull as experimental. Could you wait with the release for a Python 3.11 build of OCP?

[jmwright]

I'd mark the 2D solver and 2D hull as experimental.

Sounds good. @lorenzncode Would marking the 2D solver as experimental address your concern?

Should we mark things as experimental through the docstrings, or would it be better to use a decorator like we do with deprecation warnings?

Could you with the release for a Python 3.11 build of OCP?

The word "with" makes me unsure what you are asking. Do you mean hold the release until Python 3.11 support is ready? I think that would be fine. I've seen the commits on the OCP repo. Do we know what needs to be done on this core codebase to have it be 3.11-ready?

[adam-urbanczyk]

I meant wait with... conda-forge already has 7.6 with py3.11 and cadquery should soon.

Regarding decorators: TBH I thought mentioning it in the release notes would be enough.

[lorenzncode]

Would marking the 2D solver as experimental address your concern?

Yes. Marking in the release notes with say "(experimental)" is enough and possibly add a warning/note here too:
https://github.com/CadQuery/cadquery/blob/master/doc/sketch.rst#constraint-based-sketches

Something like

 .. warning:: The 2D Sketch constraints and solver is currently experimental.

[jmwright]

@adam-urbanczyk @lorenzncode Those experimental notes/warnings have been added.

[adam-urbanczyk]

LGTM

[jmwright]

@lorenzncode recommended that we pin the cadquery-ocp wheel version to 7.7.0a0 to match conda, so I've done that. I've structured the pin in setup.py in such a way that users shouldn't need the --pre tag when installing via pip anymore. It should also "just work" (famous last words) when the full release of 7.7.0 and later 7.7.x wheels happen.

I've also started documenting the release process so that I'm not the only one holding the keys on that task. I will complete those docs when I upload the source distribution of this repo. That will allow other core devs to be involved in beta or release candidate releases and in the 2.3.0 release, if they want. It will also help highlight tasks that are good targets for automation.

For now I'll wait for a while to allow all the checks to run and to give time for additional comment before I merge and do the release.

[fpq473]

I'm unable to pip install on linux with 3.11 because no 3.11 wheels are available for casadi (for any platform, it seems).

[jmwright]

I see Python 3.11 files in the listing mentioned here, but they haven't made it to PyPI yet. Sounds like Casadi has a small dev team that's stretched thin, so it may be a while. I'll add a note that Python 3.11 users only have the option of conda until those 3.11 wheels are available.

[jmwright]

Nevermind, we already have a note in the readme's pip section that says that installation method only supports Python 3.8-3.10.

[jmwright]

@adam-urbanczyk @lorenzncode The release has been published and tested. The instructions for publishing to PyPI are here. If either of you are interested in setting up a PyPI account, Dave and I can add you to the org on there so that you can do releases as well.

https://pypi.org/project/cadquery/