You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Added
docs: what a 1.x release may rename or remove, by tier (docs/api/stability.md, "Renames and removals after 1.0"). 1.0.0 shipped without this section, which was prepared for it in #892 and left out of the cut. The section carries the owner's rulings of 2026-10-01 on #892:
Tier 1. When a 1.x release renames a tier-1 name, the old name stays as an alias of the new one. When a 1.x release removes one, the old name stays and does what it did. Either way, a call to the old name, or a read of it where it is not callable, emits a DeprecationWarning that names the replacement or says there is none, in every later 1.x release, and 2.0 removes it. The page lists the deprecated name in tier 1 beside its replacement until then. The position of a parameter, a return shape and a documented behaviour still change only in a 2.0. This qualifies what 1.0.0 published: the page's tier-1 bullet said "A change to them is a 2.0", with no exception. It now says a 1.x release can rename or remove a tier-1 name, or a keyword parameter of one, and keep the old spelling working with a DeprecationWarning until 2.0, and that any other change is a 2.0.
Keyword parameters of a tier-1 callable follow the same rule. A renamed or removed keyword is still accepted, does what it did, and emits a DeprecationWarning through 1.x. 2.0 removes it.
Tier 2 changes only in a minor release (1.x.0), never in a patch (1.x.y), with a Breaking CHANGELOG entry that names both spellings. No alias is promised. This narrows what 1.0.0 published: the tier-2 bullet of the stability page, its "Documented but internal" section, and the [1.0.0] Highlights below say a 1.x release can change a tier-2 name with a CHANGELOG entry, which allowed a patch. The page's tier bullets, its tier-2 section and its exporter-registry subsection now say minor release and Breaking. So do the tier-2 sentences of docs/api/entities.md, docs/ocr.md, docs/analytics.md (the manifest's JSON keys, anonymized and HTML layout), docs/api/persistence.md (the audit-trail methods) and docs/api/exporters.md. The [1.0.0] Highlights are a released section and are not changed.
Tier 3: no notice.
The section also says how to see a DeprecationWarning: by default Python shows one only when it comes from code that runs as __main__.
How the policy and the tests coexist.tests/test_api_coherence.py's one-spelling pins forbid spellings deleted before 1.0 (scan_for_phi, export_to_parquet, write_project_secret/load_project_secret, the second config loader and others). None of them is a 1.0 name, so the policy does not reach them, and that test is unchanged. A future deprecated alias is a new public name on a tier-1 class, so tests/test_frozen_surface.py::test_every_public_name_on_a_tier_one_class_is_classified stays red until the page and TIER_ONE_NAMES classify it, which is the listing the policy promises. A deprecated keyword that is a real parameter moves the signature tables' pins, which is the intended review point. pytest.ini filters only ignore:::pydicom.*, so a future Isocenter DeprecationWarning is not made an error. test_the_stability_page_says_what_a_1x_may_rename_or_remove pins the section, its place above "Frozen at 1.0", and the minor-release rule wherever the pages state when tier 2 may change.
Changed
setup.py classifies Isocenter as Development Status :: 5 - Production/Stable, not 4 - Beta. 1.0.0 shipped with 4 - Beta, because this change was held in #892 and left out of the cut. PyPI shows a release's classifiers as that release uploaded them, so the 1.0.0 page keeps 4 - Beta, and the new classifier shows only from the next upload. pip ignores classifiers, so no install changes. No test ties the classifier to the version: such a test would be red on main between a change of the classifier and the record-back that sets _version.py.
The install instructions no longer offer a release candidate.README.md, docs/index.md, docs/installation.md and the home page's hero said Release candidates: pip install --pre isocenter. Now that 1.0.0 is final, pip install isocenter installs it, and --pre would install any later candidate instead (a 1.1.0rc1, say). The README line becomes "Check which version you have:", the lead-in the two docs pages already use, so the README's two code fences do not sit back to back. The hero keeps the rest of its note. 1.0.0 shipped with the old line: PyPI's 1.0.0 page reads the README as uploaded and keeps it, and the live 1.0/ site keeps it until the site is next deployed. .github/SECURITY.md said fixes go to "the latest 1.0 release candidate until 1.0.0 is final, then the latest 1.0.x release", and now says the latest 1.0.x release. Left as they are, because none is an install instruction: the 1.0.0rc3 placeholders in the issue templates, docs/midi-b.md's isocenter[textdetect]==1.0.0rc22 (it reproduces a measurement of that version), the notebooks' installs from git, and the historical 1.0.0rcN mentions in RELEASING.md, code comments and tests.