🚀 Release 0.43.1

[tkoyama010]

Patch release of v0.43.1 which includes:

• Add interactive plots in documentation #4938
• Revert "Remove comment about interactive" #4942
• Fix redirect link to fix LinkCheck CI error #5266
• Fix docstring of DataSet.cell_neighbors_levels #5293
• Fix connectivity plots in documentation #5307
• Add a step to push the branch in Minor Release Steps #5309
• Update plots before scraping #5321
• Fix issue with Report() hijacking shell output #5324
• Deploy preview document only from command #5329
• Update CITATION.cff to fix Cite this repository is not working #5330

Merge Checklist

• Merge in local NOT to squash merge.

Post Merge Checklist

• Tag v0.43.1 and push the tag.
• Verify docs have updated.
• Verify PyPI have updated.
• Update the conda-forge feedstock.

[codecov]

Codecov Report

Merging #5333 (5e7a0c0) into release/0.43 (124840e) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files

@@              Coverage Diff              @@
##           release/0.43    #5333   +/-   ##
=============================================
  Coverage         96.20%   96.20%           
=============================================
  Files               134      134           
  Lines             22712    22712           
=============================================
  Hits              21849    21849           
  Misses              863      863           

[github-actions]

🚀 Deployed on https://65794bd5681e715d3baec37a--tubular-marzipan-5e01ed.netlify.app

[banesullivan]

@tkoyama010, this actually isn't how we want to perform patch releases and this PR alone is not sufficient. The process for patches is different from minor releases in that we have to merge or cherry-pick commits onto the release branch. This can vary depending on the patches being applied. For this patch release, what we want to do is make sure all of the above PRs are merged to main, then git merge main from the release/0.43 branch and ensure the version string is set accordingly after (to version 0.43.1). The general philosophy is well outlined here in the trunk based development guide.

Since we are so close to the date of the release and we aren't considering the above to be significant features worthy of a minor release, a git merge main is appropriate here. As we move forward, the approach will be to git cherry-pick individual commits onto the release/0.43 branch.

Further, we do not want to create these patch release/ branches in the repository as the release/* pattern is protected and this non-functional branch (release/0.43.1) breaks that model.

I'm going to recreate a PR for this after #4938 merges to show the general process in this specific scenario (noting that cherry-pick will be a different process)

[banesullivan]

To outline, my process for this scenario will be:

1. git checkout release/0.43
2. git checkout -b patch/0.43.1
3. git merge main
4. Address merge conflicts (the version string most likely)
5. Bump the version to 0.43.1
6. Make sure changes are committed
7. git push --set-upstream origin patch/0.43.1
8. Open a pull request for patch/0.43.1 targeting release/0.43
9. Merge pull request
10. Tag the latest commit on the release/0.43 branch

This is more involved and hence why in the past, Alex and I have just manually done this directly on the release/0.xx branch without a PR. (a ~2 step process)

[tkoyama010]

@banesullivan Thanks for sharing your knowledge. Your procedure is better than mine. I will start over again.

[banesullivan]

To clarify: I'll handle this patch release to make sure all goes smoothly

[tkoyama010]

To clarify: I'll handle this patch release to make sure all goes smoothly

Yes, please. I'm sorry. I wrote the wrong sentence.

[banesullivan]

I want to add some additional context though: most libraries that follow this release-branching model (VTK is also one) do not typically issue a PR for approval for patch releases. Typically the process is to continually approve and land PRs onto main and noting in that PR whether or not it should be backported to the release branch. Then a single person git cherry-picks those commits onto the release branch and tags the release when deemed appropriate

[banesullivan]

I'll do a PR approach this time though to provide more transparency into the process.

And I know it may feel nitpicky that I'm raising so much concern over the branch name for this starting with release/, but it is critically important in our branching model and will leave us with a very hard to maintain branching structure for our releases

[tkoyama010]

I'll do a PR approach this time though to provide more transparency into the process.

And I know it may feel nitpicky that I'm raising so much concern over the branch name for this starting with release/, but it is critically important in our branching model and will leave us with a very hard to maintain branching structure for our releases

OK. I will try to watch what you do and learn the steps.