release : 3.2.1 release notes

[d-v-b]

release notes for 3.2.1

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/user-guide/*.md
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[maxrjones]

@d-v-b would you have any time to fix the regression from #3939 for 3.2.1? I could take a look tomorrow if you don't have time

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.23%. Comparing base (37ae37b) to head (a7a5dcb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3942   +/-   ##
=======================================
  Coverage   93.23%   93.23%           
=======================================
  Files          87       87           
  Lines       11695    11695           
=======================================
  Hits        10904    10904           
  Misses        791      791           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[d-v-b]

the two changes in this release are pretty simple bugfixes without which there is no mitigation of the underlying problem, whereas #3939 does have a mitigation and fixing the underlying issue in a satisfactory way will require some design work. so if possible i'd like to quickly release the two merged bugfixes and then get a fix for #3939 when we are happy with the design. how does that sound?

[maxrjones]

the two changes in this release are pretty simple bugfixes without which there is no mitigation of the underlying problem, whereas #3939 does have a mitigation and fixing the underlying issue in a satisfactory way will require some design work. so if possible i'd like to quickly release the two merged bugfixes and then get a fix for #3939 when we are happy with the design. how does that sound?

Couldn't we just revert the two problematic lines referenced in #3939 to resolve the regression and only release the automatic usage of ManagedMemoryStore when it's properly integrated after the more robust design effort?

[d-v-b]

the two changes in this release are pretty simple bugfixes without which there is no mitigation of the underlying problem, whereas #3939 does have a mitigation and fixing the underlying issue in a satisfactory way will require some design work. so if possible i'd like to quickly release the two merged bugfixes and then get a fix for #3939 when we are happy with the design. how does that sound?

Couldn't we just revert the two problematic lines referenced in #3939 to resolve the regression and only release the automatic usage of ManagedMemoryStore when it's properly integrated after the more robust design effort?

I'm happy to implement a fix in a new PR but I don't see why that should delay releasing a bugfix version with the 2 fixes we already merged. IMO we should release quickly, as soon as fixes are done. So in this case we have 2 fixes merged, so we can release them now, and tomorrow I can open a PR that deals with the memory store thing, and we release that quickly when it's done.

[d-v-b]

Patching over the breakage reported in #3939 is very simple. see #3944. If that PR is approved, I would probably have time to bring those changes in to this PR and we could include them with 3.2.0. later this evening. But I think my broader point about not blocking releases because of other stuff we want to release still holds -- we should normalize releasing more, rather than less.

[maxrjones]

Patching over the breakage reported in #3939 is very simple. see #3944. If that PR is approved, I would probably have time to bring those changes in to this PR and we could include them with 3.2.0. later this evening. But I think my broader point about not blocking releases because of other stuff we want to release still holds -- we should normalize releasing more, rather than less.

I feel like I'm enabling frequent releases by quickly reviewing several PRs. I was asking if you have time to unblock some of my work by quickly bundling a PR that blocks downstream work by fixing a regression. It's fine if you don't have time and need a release immediately. I don't think it's productive to say I'm blocking releases. Specifically, asking to delay a release by a single day to reduce total work seems fine. It's just an ask, not a block.

[d-v-b]

I feel like I'm enabling frequent releases by quickly reviewing several PRs. I was asking if you have time to unblock some of my work by quickly bundling a PR that blocks downstream work by fixing a regression. It's fine if you don't have time and need a release immediately. I don't think it's productive to say I'm blocking releases. Specifically, asking to delay a release by a single day to reduce total work seems fine. It's just an ask, not a block.

I totally agree that it's not productive to talk about "blocking" releases, and I'm sorry for using that terminology, and more broadly for implying that you are doing anything other than being super helpful in this process!

That being said, in principle I don't think we should delay a release for (completed) fix A while we wait for (pending) fix B, when A and B are independent. In this case, fix B is really simple so the maximum delay would not be very long, but as long as releases are cheap, I think our default should be to address this situation by releasing each repaired feature as soon as the fixes are complete.

[d-v-b]

as soon as #3944 is merged I will include it in this branch

[maxrjones]

I feel like I'm enabling frequent releases by quickly reviewing several PRs. I was asking if you have time to unblock some of my work by quickly bundling a PR that blocks downstream work by fixing a regression. It's fine if you don't have time and need a release immediately. I don't think it's productive to say I'm blocking releases. Specifically, asking to delay a release by a single day to reduce total work seems fine. It's just an ask, not a block.

I totally agree that it's not productive to talk about "blocking" releases, and I'm sorry for using that terminology, and more broadly for implying that you are doing anything other than being super helpful in this process!

That being said, in principle I don't think we should delay a release for (completed) fix A while we wait for (pending) fix B, when A and B are independent. In this case, fix B is really simple so the maximum delay would not be very long, but as long as releases are cheap, I think our default should be to address this situation by releasing each repaired feature as soon as the fixes are complete.

thanks for the clarification. That default sounds good to me

[d-v-b]

and thank you for fixing the release notes!