Loading page
About this tool
Plan announce, warn, brownout and removal dates for a deprecation, with ready-to-send comms templates.
This planner turns one announcement date plus three offsets into a complete deprecation timeline — announce, warn, brownout/disable and remove — with exact calendar dates and ready-to-send templates for the notice, the runtime warning and the removal changelog entry. It follows the staged lifecycle used across the industry: warnings before brownouts, brownouts before removal, as in Node.js deprecation levels and GitHub's pre-shutdown API brownouts. It also flags timelines that give less than 90 days of notice on public surfaces.
Open Deprecation Timeline Planner on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Announce, warn, brownout and remove each get a concrete date and a description of what happens.
Generates the announcement, the DeprecationWarning string and the removal changelog entry from your dates.
Warns when total notice falls under the common 90-day floor for public deprecations.
The standard lifecycle has four stages: announce (documentation and notice published), warn (the old path works but emits deprecation warnings), brownout or disable (the old path is switched off temporarily so remaining users notice), and remove (permanent shutdown and code deletion). Each stage exists to convert silent consumers into migrated ones before the hard cut.
It depends on the surface: 90 days is a common floor for smaller public services, while major platforms promise 6-12 months for stable APIs — Google's stable API policies, for example, commonly guarantee a year. Internal APIs with known callers can move faster. The real constraint is your consumers' release cadence: give at least one of their upgrade cycles.
A brownout is a scheduled, temporary disabling of a deprecated feature — for example returning errors for one hour — so consumers who ignored the written notice experience the failure while recovery is still trivial. GitHub used brownouts in 2020 before permanently removing password-based API authentication, and the practice is now common for API shutdowns.
Yes, under SemVer: item 7 of the 2.0.0 specification requires at least a minor version bump when public API functionality is marked deprecated. The later removal is a breaking change and requires a major bump under item 8. The deprecation release is also where your runtime warning should first appear.