Deprecations
vanzik v2.0updated view on github
This file is the single source of truth for features that are on the way out of Vanzik. Every deprecation lands here in the same commit that introduces it.
How this table is used#
- feature — a stable identifier, also used as the key passed to
deprecation.Warn(...)and exposed viavanzik_deprecations_used_total{feature="..."}for features that call it. - deprecated-in — the release that started emitting the warning.
- removal-target — the release where the feature becomes an error or is removed. Do not slip this silently; if the date moves, update this file and say why.
- migration-path — what users should do instead. Must link to code, docs, or a config snippet.
- owner — person or area responsible for following through on removal.
Before the removal release ships, check vanzik_deprecations_used_total in scraped metrics. If anyone is still using the feature, extend the timeline explicitly in this file — do not remove silently.
The two active entries below predate this convention: in 2.x neither audit.migration.v040_to_v041 nor audit.backup.v040 calls deprecation.Warn, so they log no warning and vanzik_deprecations_used_total stays at 0 for them whether or not they run. The metric cannot gate their removal; check for headerless v1 audit files and .v040-backup files instead.
Active deprecations#
| feature | deprecated-in | removal-target | migration-path | owner |
|---|---|---|---|---|
audit.migration.v040_to_v041 |
v0.4.1 | TBD (was v0.4.3 — that release never shipped; still in the binary as of v1.0.0) | Runs automatically on startup (registered via pkg/migrate/v040_to_v041, also invocable as vanzik migrate). Users still on headerless v1 audit files should migrate before the removal release, whenever it is rescheduled. |
audit |
audit.backup.v040 |
v0.4.1 | TBD (was v0.4.3 — that release never shipped; convention still active as of v1.0.0) | .v040-backup is created by the v0.4.0 → v0.4.1 migration to enable downgrade. Operators who want the backup retained long-term should archive it externally. It will be removed alongside the migration code. |
audit |
Removed (historical)#
| feature | deprecated-in | removed-in | notes |
|---|---|---|---|
policy.time_window_without_require_prior |
v0.4.1 (WARNING log) | v0.5.0 (hard policy-load error) | time_window without require_prior was a silent no-op; policies containing it now fail to load. Pair time_window with require_prior, or remove it. See POLICY_REFERENCE.md. |
Policy for removing entries from this table#
An entry moves from "Active" to "Removed" only after:
- The removal release has shipped.
- The code path is gone from the main server binary.
- The CHANGELOG entry for that release names the removal.
Otherwise the entry stays in "Active" with an updated removal-target.