release: 26.4

[dyve]

Cuts 26.4. django-marina confirmed the number: YY.N counts per package from its own last tag, and bootstrap5 is on v26.3, so 26.4. Breaking changes do not move the number; the **Breaking:** prefix is the only signal those users get.

Three entries just release-check could not see

just release-check lists only commits touching src/. Since v26.3 there are 23 commits and it reports 2. Four of the rest changed nothing under src/ but are worth telling people about, so this adds three entries and amends one:

• Harden the workflows, and write down the dependency update policy #887, workflow hardening. The Dependabot auto-merge job gated on github.actor, which is spoofable in a pull_request_target context. The publishing job restored a build cache, so a poisoned entry could have reached what goes to PyPI. Jobs had no timeout-minutes and ci.yml had no permissions. None of that was in the changelog.
• Fail lint on invisible and bidirectional control characters #875, invisible and bidirectional control characters now fail just lint (Trojan Source, CVE-2021-42574).
• Add the shared AI assistance policy to CONTRIBUTING.md #874, the shared AI assistance policy in CONTRIBUTING.md.
• Check coverage against the floor in CI #888 is folded into the existing coverage entry, which said the floor was held at 100% when until that commit nothing in CI ran coverage report.

I left out the two AGENTS.md commits (#869, #870) and the three Dependabot dev-dependency bumps, which do not reach users, and the un-cut of the accidental 26.4 (#885), which corrects something never published.

Ordering

MAINTAINING.md lists the category order and the Unreleased section was not in it. The 26.4 section now runs dropped cycles, bug fixes with the breaking ones first, features, tooling, documentation. Flat list with no subheadings, matching 26.3 and earlier.

uv.lock, and a warning worth keeping

marina passed on the lesson that uv.lock must name the new version after a bump, since bootstrap4's accidental 26.3 left the lock on 26.2. Checking it here turned up something sharper than the diagnosis.

just install runs uv sync --frozen, and just build runs install. I bumped pyproject.toml to 26.4, ran a full just build, and it passed: it produced django_bootstrap5-26.4 wheel and sdist, passed twine, check-manifest, pyroma at 10/10 and both smoke tests, while uv.lock still said 26.3. So --frozen does not catch a stale version for the project's own package, and a release PR that runs just build is not the safety net it looks like.

Relocked with uv lock, which changed exactly that one line. There is no just recipe for relocking without also upgrading every dependency, which seems worth adding; I will raise that with marina rather than invent one here.

One thing I did not change

- **Breaking:** Drop support for Python 3.10 carries the prefix, as merged in #894. 26.3's - Drop support for Django 4.2 (EOL). does not. Dropped cycles are their own category above bug fixes, so the prefix is arguably redundant there, but it is also arguably more correct. I left it as merged rather than quietly edit someone's merged wording. Worth settling for next time.

Checks

just lint, just test-cov at 100%, just build.

After merge the remaining steps are just build on main and just release-tag, which I will not run without being asked.

🤖 Generated with Claude Code

[dyve]

Resolving the one open question in the description, and recording two checks.

The **Breaking:** prefix stays as #894 merged it. django-marina settled it: by the letter of MAINTAINING.md the prefix is redundant on a dropped cycle, since those already sort in their own category above bug fixes. It stays anyway because the same prefix is already published in marina v26.3 and django-icons v26.3 and merged in django-bootstrap4, so changing course here would make one repo disagree with four over a rule that was ambiguous when it was written. It is also defensible on its own terms: raising requires-python does break installs, and the category only helps a reader who knows the ordering. The wording in MAINTAINING.md gets settled in a later pass rather than mid-release. Nothing to change in this PR.

The lock gap is fixed upstream, in zostera/django-marina#694, which adds a _lockfile-matches-version check that build depends on (so it also gates release-tag), a just relock that is uv lock and nothing else, and a line in MAINTAINING.md's step 2. Not propagated here while this PR is open, which is the rule from zostera/django-marina#693 that the accidental 26.4 broke last time.

No published damage, checked rather than assumed. uv.lock is in source-exclude and check-manifest's ignore list, so it ships in neither artefact. Confirmed against this branch's own build: uv.lock is absent from both django_bootstrap5-26.4-py3-none-any.whl and django_bootstrap5-26.4.tar.gz. For the record, our own v26.3 tag does carry a stale lock, 26.3.dev0 against a pyproject saying 26.3, but it reached nobody through PyPI and only affects someone checking out that tag.

[dyve]

Rebuilt on top of #896, which merged into main ahead of this one. Three things changed.

#896's three entries are now in the 26.4 section, not left for 26.5. The plan django-marina and I agreed was that this PR merges first, v26.4 gets tagged, and #896 lands afterwards for 26.5. The opposite happened: #896 merged at 09:42. Since it is in main, it is in the tree this tag will point at, so its entries have to be in the notes this tag ships. Leaving them in Unreleased would have given exactly the mismatch between tree and notes that the agreed order existed to prevent, just from the other direction.

Worth noting it would not have failed loudly. This branch rewrites the top of the Unreleased block and #896 appended to the bottom after a blank line, so git reported BEHIND, not CONFLICTING. A plain merge would have filed three tooling entries at the foot of a dated section, or orphaned them between sections, without anything going red. Rebuilt from current main instead of resolving it.

(release candidate) is gone from the Python 3.15 entry. 3.15.0 shipped on 2026-10-09, so it was false. Checked PyPI rather than assuming: Django 6.1.2, 6.0.9 and 5.2.18 all still stop at 3.14 in their classifiers, so it is Django and not CPython that keeps 3.15 out of ours. The entry now says that. It was the last occurrence in the repository; #894 had already fixed the workflow and tox comments.

The audit holds, and just release-check now confirms it independently. #896 made the recipe print a second group for commits touching nothing in src/. That group lists #887, #888, #875 and #874, the four I had found by reading the log by hand. Nothing else in it needed an entry: #869 and #870 are AGENTS.md, #885 un-cuts a version that was never published, and three are Dependabot dev-dependency bumps.

The new gate earned its keep immediately. After the version bump, just build failed with Error - pyproject.toml says 26.4, uv.lock says 26.3. Run 'just relock'. That is the check #896 brought over from zostera/django-marina#694, catching on its first run here the exact class of mistake that left three sibling tags carrying a stale lock.

25 entries now. just lint, just test-cov at 100%, just build all green.