[Polichinel]

MERGE COMMIT ONLY — never squash, never rebase

A squash creates yet another commit that is not main, so main still would not be an ancestor of
development and this PR would have to be opened again. That is not a style preference: it is the
failure this PR exists to repair, and squashing it reopens it.

Why this exists

Promoting development → main through a PR (#504) leaves a merge commit on main that
development has never seen:

b0c0b17 Merge pull request #504 from views-platform/development

One commit, always exactly one, every release. Expected immediately after a release and a problem
only if it persists — so this PR is the last step of the v1.15.0 release, not a separate task.

Left unhealed the divergence accumulates: git log main..development starts counting work that
already shipped, and the next release's diff begins from a base that no longer reflects reality.
This step was skipped after every release before v1.10.0.

What is currently red because of it

Both are real failures, not cosmetic, and both go green when this merges:

Check	Where
TestF2ReleaseTopology::test_main_is_ancestor_of_development	tests/test_falsification_deploy_v160.py:159
TestDF1MergeTopology::test_main_ancestor_of_development	tests/test_falsification_deploy_v160_r2.py:50
Release hygiene workflow	auto-opened #505, which closes when the topology heals

The two tests carry their own remedy in the assertion message, which is why this was expected rather
than investigated.

v1.15.0 release state

Step	Result
#503 bump merged to development	7cef97f
#504 promotion to main as a merge commit	b0c0b17
Tag v1.15.0	b0c0b173a, same commit as origin/main
test_version_equals_the_tag_head_is_on	ran and passed — first time this release; it can only run with HEAD tagged
GitHub Release + Publish Package	success
PyPI	views-datafactory 1.15.0
Clean-venv install (Python 3.13, uv pip install views-datafactory==1.15.0)	metadata reports 1.15.0; all nine datafactory_* packages import
Deploy to the server	not done — four blocks of server_quickref.md, still pending

The clean-venv check is the guide's requirement — verify by installing the published artifact, not by
reading a green tick. Worth recording how it first failed: a venv built on Python 3.10.14 reported
No matching distribution found against requires-python = ">=3.11". The broken thing was the
check, not the release, and a less careful reading of that message would have looked like a failed
publish.

Refs #501, #505.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EfeuULbPTqrx4qtNki5dy9