python-filelock (4.0.1-1) unstable; urgency=medium

  Upstream version 4.0.0 changed the on-disk protocol of SoftReadWriteLock.
  A lock directory is now a generation log below "<lock_file>.rw", replacing
  the ".state", ".write" and ".readers/" sidecar files used by 3.x. Processes
  running 3.x and 4.x do not see each other's locks at all: they will happily
  enter the same critical section instead of raising an error. If a
  SoftReadWriteLock path is shared between hosts, for instance on NFS or on
  cluster storage, upgrade all participating hosts together, and make sure no
  lock is held while you do. Only versions 3.27.0 up to 3.32.6 are concerned
  here, which in Debian means unstable and testing since 3.29.0-1 was uploaded
  in April 2026; the 3.18.0 in Debian 13 (trixie) predates the class entirely
  and has no SoftReadWriteLock.

  SoftReadWriteLock now also requires hard links on the filesystem holding the
  lock file. Where os.link is unavailable or refused, acquiring raises
  filelock.SoftFileLockProtocolError instead of working as it did in 3.x.

  Independently of the above, the poll_interval option of all lock classes,
  FileLock and SoftFileLock included, is now validated. Negative values, NaN
  and infinity raise ValueError; values that are not real numbers, booleans
  among them, raise TypeError. This happens in the constructor, in the
  property setter and in acquire(). Code that passed such a value, for example
  poll_interval=-1 by confusion with timeout=-1, used to be accepted silently
  and now fails at once.

  The importable API is otherwise unchanged: no name was removed, renamed or
  given an incompatible signature in 4.x.

 -- Sascha Steinbiss <satta@debian.org>  Sat, 19 Sep 2026 21:46:43 +0200