v0.14-DEV: Consolidate nomenclature to IntegrationRule

[mikeingold]

Completed

• Rename IntegrationAlgorithm to IntegrationRule (breaking)
• Update all old references from "algorithm", "settings", etc to "rule"

[JoshuaLampert]

Thanks! I have only one minor suggestion below. What is your plan regarding the branches? Do you want to merge this into main or into another branch as you say in this PR?

[mikeingold]

What is your plan regarding the branches? Do you want to merge this into main or into another branch as you say in this PR?

At first my plan was to create, effectively, a v0.14 branch. Then I'd create sub-branches for sizable tasks and PR those individually into the v0.14 branch. Then, when ready, we'd PR the v0.14 branch into main. As I was working on this task, though, that started to seem a little extravagant. The ultimate PR would still show a diff including all of the sub-PR's contents merged together, so there'd still be some mental accounting to ensure all of the commits came from reviewed PR's or were reviewed at that stage.

What I decided to move towards was just PR'ing these tasks direct to main but with Project.toml version v0.14-DEV. Once all of the planned changes are implemented, we'd just need to drop -DEV from the version and trigger registration. I think the other process above could probably make sense for a huge change (e.g. v1.0 to v2.0), a protracted development cycle, and/or with a much larger user base, but it might just be a little too much overhead in this particular case.

Let me know if that makes sense or if you disagree.

[JoshuaLampert]

Thanks for the detailed explanation. I agree with you and your plan sounds reasonable!

[JoshuaLampert]

One question, however, remains: What do we do with the non-breaking PRs I opened?

1. Do we want to merge them before this PR (and others containing breaking changes) and then create a new non-breaking release before?
2. Do we want to merge them after the breaking release and make a new non-breaking release in the v0.14 cycle?
3. Do we just include them in the breaking release?
4. Do you think they are not even worth merging?

I plan to create one more PR including tests using ExplicitImports.jl if you agree that this makes sense.

[codecov]

Codecov Report

Attention: Patch coverage is 94.50549% with 5 lines in your changes missing coverage. Please review.

Project coverage is 90.35%. Comparing base (8d5f81a) to head (c8d7bda).
Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
src/specializations/Ring.jl	50.00%	2 Missing ⚠️
src/specializations/Rope.jl	50.00%	2 Missing ⚠️
src/specializations/BezierCurve.jl	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #82   +/-   ##
=======================================
  Coverage   90.35%   90.35%           
=======================================
  Files          16       16           
  Lines         311      311           
=======================================
  Hits          281      281           
  Misses         30       30           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mikeingold]

One question, however, remains: What do we do with the non-breaking PRs I opened?

I just went ahead and merged the downgrade PR. That looked non-conflicting and should still be merge-able with this one. Since there's really no functional changes, just updated compat bounds, I don't know if it's worth pushing another v0.13 release. We can probably just keep rolling toward a v0.14.0 release that incorporates all of these changes.

I like the idea of the JuliaFormatter PR but had a comment/question on which particular code style to enforce, so it might be better to re-run the suggested changes and put that PR in line after this one.

[JoshuaLampert]

Ok, so this means we go with option 3. from above 👍 This means we can merge this PR, I guess.