liveBook · Manning

Current state

As explained in API Design Patterns

Current is the API version lifecycle state for the primary version offered to users with changes restricted to mandatory requirements and critical fixes.

Current marks the primary API version offered to real users. Treat it as a stable compatibility contract: allow only mandatory requirements, such as security patches, and critical bug fixes. section 24.3.2

Use the lifecycle deliberately:

  • Freeze the current version rather than continuing ordinary feature development. section 24.3.2
  • Put new features and noncritical changes into the next Preview version. section 24.3.2
  • When the next version becomes current, move the existing current version to Deprecated instead of deleting it. section 24.3.2

Version 1 and version 2

After version 1 matures, label it Current and preserve client behavior. Develop new functionality in version 2 as Preview. When version 2 becomes Current, mark version 1 Deprecated while retaining its mandatory-change policy. section 24.3.2

How API Design Patterns covers it

How deep it goes
Defines the state, permitted changes, and transitions to Deprecated, but does not detail implementation mechanics.
Examples
Uses version 1 and version 2 in a staged timeline from Preview through Current and Deprecated.
What it assumes
Assumes API versioning and client compatibility, while distinguishing Preview, Current, Deprecated, and Deleted from their policies.
What you can do after
Operate API releases by freezing the current version and routing new features into the next Preview.
How it connects
Connects API versioning with Preview, Deprecated, Deleted, compatibility, security patches, and critical bug fixes.

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.