Require marshmallow 4 or later

[Marenz]

The code has required marshmallow 4 since 4ddc29d; the metadata still advertises 3.x, which cannot import.

Correct the dependency floor and document the required consumer upgrade.

[Copilot]

Pull request overview

This PR adds backwards-compatible support for marshmallow 4.x by migrating from schema context-based serialization configuration to Python's ContextVar. The changes maintain full API compatibility while deprecating the old constructor-based approach.

Key changes:

• Introduces serialize_as_string_default as a ContextVar for controlling serialization format globally
• Deprecates the serialize_as_string_default constructor parameter with a DeprecationWarning
• Adds backwards compatibility handling in _QuantityField.__init__ to check metadata for per-field configuration

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
src/frequenz/quantities/experimental/marshmallow.py	Adds QuantitySchema.__init__ with deprecation logic and backwards compatibility for metadata-based field configuration
tests/experimental/test_marshmallow.py	Adds two new tests to verify the deprecated constructor API works correctly with both True and False values
RELEASE_NOTES.md	Documents the API changes, migration path, and rationale for the marshmallow 4.x compatibility update

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[llucax]

OK, this is a tricky one, and a reason why we might want to split marshmallow support into a separate package at some point.

For people using marshmallow, this is in fact a breaking change, as marshmallow 4.0 is required, not just optional, but for users not using marshmallow is not a breaking change.

Normally, if any part of the code is backwards incompatible, even if unused, should be a breaking release, I think this should be a breaking release too. The only reason we could try to sell this as a non-breaking release would be because it is an experimental package. But still, we are supposed to be committed to not break even those.

What we could do to keep this backwards compatible, is getting the installed marshmallow version and import a different module that is compatible with one or the other version conditionally based on that.

But I think in this case it makes sense to just bite the bullet and release it as a breaking change. For users not using marshmallow, it will be just changing the dependency and changing no code. For users using marshmallow, they are going through a marshmallow upgrade anyway, so fixing one more piece of code should not be too bad.

I'm not sure if keeping the deprecated ctor makes sense if we ship this in a breaking release anyway. It might ease the upgrading a bit for users if they don't need to make any other marshmallow-related updates, so we could keep it if we want to be extra nice, and only remove the deprecated ctor in v3, but I'm not sure it is worth the trouble.

[Marenz]

I think I would be in favor of just breaking it then without a compatible c'tor :)

[Marenz]

🤖 Resolved the three stale Copilot threads: they all concerned the serialize_as_string_default shim, which this PR no longer contains — the diff is now just the dependency floor correction plus the release note.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.