From 88ee45d805469a0fcb33cc267a6738bf98a8c060 Mon Sep 17 00:00:00 2001 From: Fabian Date: Wed, 19 Aug 2026 08:15:26 +0200 Subject: [PATCH] fix merged release notes --- doc/release_notes.rst | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/doc/release_notes.rst b/doc/release_notes.rst index 9e53153a..1ee7166f 100644 --- a/doc/release_notes.rst +++ b/doc/release_notes.rst @@ -4,15 +4,6 @@ Release Notes Upcoming Version ---------------- -**Bug fixes** - -* A multi-key ``groupby`` now returns its groups sorted by key tuple, like the single-key path. The key combinations were numbered by iterating a ``set``, so the group order was arbitrary and changed between processes with ``PYTHONHASHSEED``. - - -Version 0.9.1 -------------- - -**Features** *Strict "v1" arithmetic semantics (opt-in)* @@ -59,6 +50,17 @@ Version 0.9.1 * Mutation via assignment to ``Variable.lower`` / ``Variable.upper`` / ``Constraint.coeffs`` / ``Constraint.vars`` / ``Constraint.lhs`` / ``Constraint.sign`` / ``Constraint.rhs`` is deprecated and emits a ``DeprecationWarning``. Use ``Variable.update(...)`` / ``Constraint.update(...)`` instead — the canonical mutation API with one validation path and one place that flips the persistent-solver dirty flag. Read access to these properties is unchanged. The setters will be removed in a future release. * Passing a raw ``DataArray`` of integer labels to ``Constraint.vars = ...`` setter is deprecated and emits a ``FutureWarning``. Pass a ``Variable`` to ``Constraint.update()`` instead — it is the supported input. The ``DataArray`` path will be removed in a future release. + +**Bug fixes** + +* A multi-key ``groupby`` now returns its groups sorted by key tuple, like the single-key path. The key combinations were numbered by iterating a ``set``, so the group order was arbitrary and changed between processes with ``PYTHONHASHSEED``. + + +Version 0.9.1 +------------- + +**Features** + *Named expressions* * You can now store expressions in the model and get them back by name. ``Model.add_expressions`` registers a ``LinearExpression`` or ``QuadraticExpression`` under a name (auto-named ``expr0``, ``expr1``, ... if you don't pass one). Registered expressions live in ``Model.expressions``, a container that works like ``Model.variables`` and ``Model.constraints``, and are removed with ``Model.remove_expressions``. They survive ``Model.to_netcdf``/``linopy.read_netcdf``, ``Model.copy``, ``copy.copy``, ``copy.deepcopy`` and pickling. (`#882 `__)