liveBook · Manning

Lifecycle

As explained in API Design Patterns

A version lifecycle is the ordered progression of an API version through preview, current, deprecated, and deleted states.

A version lifecycle moves an API version through Preview, Current, Deprecated, and Deleted states, balancing rapid delivery against compatibility and maintenance costs. section 24.3.2

Use each state with a deliberately narrow change policy:

  • Preview permits all changes while functionality remains unstable and users accept possible breakage. section 24.3.2
  • Current freezes the version except for mandatory changes and critical bug fixes, protecting client code. section 24.3.2
  • Deprecated marks a former Current version for impending removal under a deprecation policy. section 24.3.2
  • Deleted removes or makes the deprecated version inaccessible. section 24.3.2

Sliding-window API releases

Version 1 starts as Preview in January, becomes Current in February, Deprecated in March, and Deleted in May. Meanwhile, newer versions progress through the same sequence, keeping feature work moving without modifying the stable version. section 24.3.2

Table 24.1 Overview of different version states (view table figure)

State

Description

Change policy

Preview

An unstable and still-in-progress preview of functionality users should expect to exist in the next current version

All changes permitted

Current

A very stable set of functionality that should not change and can be expected to continue running for some pre-decided amount of time

Only mandatory changes

Deprecated

A prior current version that is scheduled for impending removal according to the deprecation policy

Only mandatory changes

Deleted

A prior deprecated version that has been removed or otherwise made inaccessible to users

N/A

Compare the four lifecycle states with their descriptions and permitted changes. section 24.3.2

How API Design Patterns covers it

How deep it goes
Defines four states, their change policies, and a month-by-month progression, but does not detail implementation mechanics.
Examples
Uses a demo API timeline in which five versions successively occupy Preview, Current, Deprecated, and Deleted states.
What it assumes
Assumes API users can manage frequent deprecations and deliberately teaches the stability expectations of each lifecycle state.
What you can do after
Evaluate API release policies by assigning versions explicit states and limiting changes according to lifecycle stage.
How it connects
Connects versioning with compatibility, deprecation policy, client code stability, and API maintenance.

Also explained in

Compare how 6 books explain lifecycle →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.