Software release life cycle

The software release life cycle is the sequence of stages through which a version of software progresses from active development and preliminary testing to public release, maintenance and eventual retirement. A release life cycle may include development snapshots, alpha versions, beta versions, release candidates, stable releases, maintenance updates, long-term-support periods and an announced end of support.

The terms used for these stages are conventions rather than a single universal standard. Different developers may assign different meanings to labels such as alpha, beta, preview, stable and long-term support. For example, the Python project publishes alpha, beta, release-candidate and final releases, while Chromium-based products use channels such as Canary, Dev, Beta and Stable.

The release life cycle is related to, but narrower than, the software development life cycle. The United States National Institute of Standards and Technology defines the software development life cycle as a methodology for designing, creating and maintaining software. A release life cycle focuses specifically on preparing, distributing, supporting and retiring particular software versions or release streams.

Overview

A traditional release life cycle may progress through the following stages:

Common software-release stages

Stage	Typical purpose	Expected stability	Intended audience
Pre-alpha	Design, implementation and early integration	Very low or unknown	Developers and internal testers
Alpha	Early functional testing and feature development	Low	Developers, internal testers and selected technical users
Beta	Broader testing, compatibility review and defect discovery	Moderate, but not production-guaranteed	Testers, early adopters and selected customers
Release candidate	Final validation of a build considered suitable for release	High, unless a release-blocking defect is found	Testers, maintainers and deployment evaluators
Stable or final release	Normal supported use	Production-oriented	General users and organizations
Maintenance	Defect corrections, security updates and compatibility work	Expected to remain stable	Existing users
Deprecation	Migration away from obsolete features or versions	Varies	Existing users and administrators
End of support	End of routine maintenance or technical assistance	No longer maintained under the former policy	Users completing migration
End of life	Retirement of the release or product	Unsupported	Archival or exceptional legacy use

A project may omit stages, combine them, rename them or operate several stages simultaneously. Web services may deploy changes continuously rather than producing a small number of individually packaged releases. Large products may also maintain several supported versions at the same time.

Terminology

Build

A build is a particular compiled, packaged or otherwise assembled form of software produced from a defined set of source code and dependencies. Builds may be created automatically after source changes, on a schedule or for a particular testing milestone.

A build identifier may contain:

• a version number;
• a source-control commit identifier;
• a build-system sequence number;
• a date or timestamp;
• a target platform;
• a distribution channel; or
• a pre-release label.

Not every build becomes a release. Development teams may generate many internal builds while publishing only those that meet defined quality, security and documentation requirements.

Release

A release is a version or iteration intentionally packaged and made available to an audience. GitHub describes releases as deployable software iterations that can be packaged and made available for others to download and use.

A release may consist of:

• executable or installable packages;
• source-code archives;
• container images;
• mobile application packages;
• firmware images;
• library packages;
• database migrations;
• configuration files;
• release notes;
• checksums;
• cryptographic signatures; and
• software-composition or provenance records.

A release can be public, private, internal, experimental or restricted to a selected group.

Deployment

A deployment is the act of installing or activating software in an environment. Release and deployment are related but not identical.

A release can be published without being deployed by every user. Conversely, a continuously delivered service may deploy an internal build without offering users a separately downloadable release package.

Release train

A release train is a scheduled sequence in which changes move through defined branches, channels or environments. Features that meet a cutoff join a particular train, while incomplete work is postponed to a later train.

Release trains are commonly used to make delivery dates predictable even when the exact feature set varies.

Pre-release stages

A pre-release is a version distributed before the project considers it a complete production release. Pre-releases allow developers and users to discover defects, test compatibility and evaluate behavior before broad deployment.

Pre-release software may:

• change without backward-compatibility guarantees;
• contain incomplete features;
• have limited documentation;
• corrupt or alter data;
• expose security weaknesses;
• perform poorly;
• omit migration tools;
• be incompatible with future builds; or
• be withdrawn without a normal support period.

Users should not assume that a pre-release is suitable for production merely because it can be downloaded publicly.

Pre-alpha

Pre-alpha is an informal term for software produced before the project reaches its alpha milestone. It may include:

• prototypes;
• proof-of-concept implementations;
• nightly builds;
• development snapshots;
• incomplete user interfaces;
• partially integrated components;
• engineering demonstrations; and
• internal testing packages.

A pre-alpha build may not implement the product's planned core functionality. Interfaces, data formats and system requirements may change substantially.

Some projects use labels such as:

• development;
• snapshot;
• nightly;
• experimental;
• prototype;
• milestone;
• trunk;
• main branch; or
• canary.

These labels do not necessarily describe equivalent levels of stability.

Alpha

An alpha release is an early testable version produced while development is still active. Alpha versions are commonly used to validate architecture, core functionality, interfaces and integration between components.

An alpha release may:

• lack planned features;
• contain known serious defects;
• use temporary user-interface elements;
• change stored-data formats;
• include debugging code;
• provide limited upgrade paths; and
• receive little or no production support.

Alpha testing may be conducted internally or made available to a restricted external audience. An open alpha is available to a broad public audience, while a closed alpha is limited to invited testers or organizations.

The meaning of alpha is project-specific. In Python's release process, alpha releases permit the incremental addition of features before the beta stage begins.

Beta

A beta release is generally more complete and stable than an alpha release but remains under active testing. Beta releases are used to obtain broader feedback, test real-world hardware and workloads, identify compatibility problems and locate defects that were not discovered by internal testing.

A beta may be described as:

• feature-complete;
• feature-frozen;
• substantially complete;
• public preview;
• customer preview;
• early access; or
• test release.

These descriptions are not interchangeable unless the project defines them as such.

During Python's annual release process, the beta phase prohibits new features while allowing defect corrections. Other projects may continue adding or changing features during beta testing.

A closed beta is offered to a limited set of testers. An open beta is available to the general public, although the publisher may still restrict geographic regions, supported devices, account eligibility or usage.

Beta testing may examine:

• functional correctness;
• performance;
• usability;
• accessibility;
• installation and upgrades;
• backward compatibility;
• hardware compatibility;
• network behavior;
• localization;
• security;
• data migration; and
• interoperability with external services.

The existence of a beta label does not guarantee that a product has undergone a particular testing method or reached a consistent level of quality.

Release candidate

A release candidate, commonly abbreviated RC, is a build considered potentially suitable for final release. A release candidate is normally replaced only when testing reveals a defect serious enough to prevent publication.

Projects may publish several candidates:

2.0.0-rc.1
2.0.0-rc.2
2.0.0-rc.3

A release candidate may be evaluated for:

• release-blocking defects;
• upgrade and downgrade behavior;
• package integrity;
• installation on supported platforms;
• security regressions;
• performance regressions;
• documentation accuracy;
• localization completeness;
• licensing information;
• artifact reproducibility; and
• compatibility with supported dependencies.

Python uses the suffix rcN for release-candidate versions and publishes one or more candidates before a final feature release.

Terms sometimes used for a similar milestone include:

• gamma;
• final candidate;
• pre-release;
• release preview; and
• escrow build.

The term release candidate should not be interpreted as a guarantee that the build will become the final release unchanged.

Preview and early-access releases

Preview, early access, technology preview and similar labels are product-specific terms. They may describe experimental features, public testing programs or functionality distributed before full support commitments apply.

A preview may differ from a traditional beta by having:

• no guaranteed production support;
• limited service-level commitments;
• restricted geographic availability;
• incomplete legal or compliance coverage;
• temporary pricing;
• usage limits;
• no migration guarantee; or
• possible removal before general availability.

Publishers should define what support, security, data-retention and compatibility commitments apply to each preview program.

Production release

Final release

A final release is the completed version that follows the project's pre-release sequence. In version identifiers, the absence of an alpha, beta or release-candidate suffix often indicates a final release.

For example:

3.2.0a1    alpha
3.2.0b1    beta
3.2.0rc1   release candidate
3.2.0      final release

The word final refers to the completion of that release process, not to the end of all development. Later patch, minor or major versions may follow.

Stable release

A stable release is a version intended for normal supported use. Stable does not mean that the software contains no defects. It generally means that the publisher considers the version sufficiently tested and controlled for its intended production audience.

Chromium identifies Stable as its most tested normal-use release channel, while Beta, Dev and Canary provide progressively earlier access to changes.

A stable release may still receive:

• security corrections;
• defect fixes;
• performance improvements;
• compatibility updates;
• documentation corrections; and
• limited feature changes permitted by the project's policy.

General availability

General availability, abbreviated GA, is the point at which a product or version is made broadly available under its normal commercial, licensing and support conditions.

General availability may include:

• public downloads;
• production support;
• published service-level commitments;
• stable APIs;
• normal pricing;
• documentation;
• migration guidance; and
• availability through standard distribution channels.

A product can be generally available while still being deployed gradually by region, account, device or update ring.

Release to manufacturing

Release to manufacturing, abbreviated RTM, traditionally referred to the build approved for duplication onto physical media or installation on manufactured hardware. The term became common when software was distributed through discs and preinstalled computer systems.

In modern distribution, RTM may instead mean:

• the build delivered to hardware partners;
• the initial production build;
• the build submitted to an application store;
• a code-complete milestone; or
• a version released before general public availability.

RTM and GA may refer to the same build but different dates. Their exact meanings depend on the publisher.

Gold master

A gold master or golden master is a version selected as the source from which production copies are created. The term originated with physical-media duplication but may also describe an approved reference artifact.

Modern release systems more commonly identify the approved artifact through immutable package hashes, signed tags, build provenance or controlled artifact repositories.

Release channels

A release channel is a distribution stream representing a particular balance between new functionality, testing exposure and stability.

A channel-based system may include:

Typical release-channel progression

Channel	Purpose	Typical update frequency	Relative risk
Nightly or Canary	Earliest integration and automated testing	Very frequent	Highest
Dev	Developer evaluation and early external testing	Frequent	High
Beta	Broader testing before stable promotion	Regular	Moderate
Stable	Normal production use	Controlled	Lowest among normal channels
Extended Stable or LTS	Reduced change frequency and longer maintenance	Less frequent	Controlled for long-lived deployments

Chromium's documented channels range from Canary, which receives early and comparatively less-tested changes, through Dev and Beta to Stable.

Channel promotion allows substantially the same code line to receive progressively broader testing. A defect found in one channel may be corrected before the build advances to the next.

Channels may also be called:

• rings;
• tracks;
• branches;
• streams;
• cohorts;
• tiers; or
• update lanes.

A user may remain on one channel or move between channels, subject to the publisher's upgrade and data-migration rules.

Post-release maintenance

After a stable release, a project may enter a maintenance period. Maintenance can include defect corrections, security updates, performance work, compatibility changes and limited improvements.

The exact maintenance policy should identify:

• which versions are supported;
• what kinds of changes are accepted;
• how long support continues;
• whether upgrades are required;
• which platforms remain supported;
• how vulnerabilities are reported;
• how quickly critical defects are addressed; and
• when users will be notified of retirement.

Patch release

A patch release primarily corrects defects or security issues without intentionally introducing incompatible changes.

Under Semantic Versioning, a normal version has the form:

MAJOR.MINOR.PATCH

The specification defines:

Component	Incremented when	Example
Major	Incompatible public-API changes are introduced	2.4.1 to 3.0.0
Minor	Backward-compatible functionality is added	2.4.1 to 2.5.0
Patch	Backward-compatible defect corrections are made	2.4.1 to 2.4.2

Semantic Versioning applies these meanings to software that declares a public API. A project's use of three-part numbers does not necessarily mean that it follows the specification.

Maintenance release

A maintenance release is a version issued after a production release to improve reliability, security or compatibility. Depending on the project, it may be synonymous with a patch release or may include a broader set of low-risk changes.

Service release

A service release is a maintenance package containing corrections or improvements for an existing version. Publishers may use labels such as:

• service release;
• service pack;
• update rollup;
• cumulative update;
• point release; or
• maintenance pack.

The label does not by itself determine whether the update contains security fixes, features or breaking changes.

Hotfix

A hotfix is an urgent correction distributed outside the ordinary release schedule. Hotfixes commonly address:

• actively exploited vulnerabilities;
• severe data loss;
• service outages;
• installation failures;
• regulatory problems; or
• critical regressions.

A hotfix may later be incorporated into the next scheduled cumulative or patch release.

Security update

A security update corrects one or more vulnerabilities or reduces security risk. Security updates may be released independently or included with other maintenance work.

NIST's Secure Software Development Framework recommends that software producers maintain policies covering the full software life cycle, including vulnerability response and notification of impending end of support.

Long-term support

A long-term-support release, abbreviated LTS, receives maintenance for a longer period than ordinary releases. LTS versions are commonly intended for organizations that prioritize stability and predictable maintenance over rapid feature adoption.

An LTS policy may provide:

• an extended security-update period;
• a stable application programming interface;
• limited feature changes;
• certified hardware or software combinations;
• migration guidance;
• extended technical assistance; or
• optional paid support after the standard period.

The term LTS has no universal duration. Users should consult the publisher's exact policy rather than assuming that every LTS release receives the same number of years or the same types of updates.

A project may maintain several streams simultaneously:

Current feature release
Current LTS release
Previous LTS release
Security-only legacy release
Unsupported archived releases

Deprecation

Deprecation is the process of discouraging continued use of a feature, interface, platform or version before it is removed or unsupported.

A deprecation notice should ideally identify:

• what is being deprecated;
• why the change is occurring;
• the first version containing the warning;
• the planned removal date or version;
• the supported replacement;
• migration instructions; and
• known compatibility effects.

Deprecation can apply to:

• APIs;
• command-line options;
• configuration settings;
• database formats;
• programming-language features;
• operating systems;
• hardware architectures;
• network protocols;
• plugins;
• authentication methods; or
• complete software versions.

Deprecated functionality may continue working temporarily. Deprecation should not be confused with immediate removal.

End of support and end of life

End of mainstream support

Some publishers divide support into phases. A mainstream period may include defect fixes, security updates, feature requests and general technical assistance. A later extended period may provide only security updates or paid support.

The names and services included in each phase vary by publisher.

End of support

End of support is the date after which a publisher no longer provides some or all routine maintenance or assistance for a version.

After end of support, users may no longer receive:

• security updates;
• defect corrections;
• compatibility updates;
• technical support;
• regulatory updates;
• documentation maintenance; or
• cloud-service connectivity.

Microsoft distinguishes products with defined support dates under its Fixed Lifecycle Policy from products and services supported continuously under its Modern Lifecycle Policy, provided users remain current and satisfy the policy's requirements.

End of life

End of life, abbreviated EOL, is the retirement point at which a release or product is no longer actively maintained under its former policy.

End of life may involve:

• removing downloads;
• disabling update servers;
• ending security maintenance;
• closing support cases;
• archiving source repositories;
• disabling hosted services;
• ending license sales;
• removing application-store listings; or
• directing users to a replacement product.

End-of-life software may continue operating, but its continued use can create security, compatibility, legal and operational risks.

Retirement and sunset

Retirement, sunset and discontinuation are related terms often used for hosted services, APIs and commercial products. A retirement plan may require customers to export data, migrate integrations or adopt a successor service before a specified date.

A responsible retirement process should address:

• advance notification;
• migration paths;
• data export;
• data deletion;
• archival access;
• contractual commitments;
• dependency impact; and
• security after shutdown.

Version identifiers

Version identifiers distinguish releases and communicate ordering or compatibility expectations.

Common patterns include:

1.0
1.0.5
2.3.0-beta.2
2026.07
15.4 LTS
Build 18452
Release 7 Update 3

A version identifier may reflect:

• compatibility;
• development sequence;
• calendar date;
• marketing generation;
• maintenance level;
• platform;
• branch; or
• build history.

Version numbers should not be assumed to follow numerical or semantic rules unless the project documents them.

Pre-release identifiers

Semantic Versioning permits a hyphen followed by a pre-release identifier:

1.0.0-alpha
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-rc.1

A pre-release version has lower precedence than the corresponding normal version:

1.0.0-rc.1 < 1.0.0

Build metadata can be appended with a plus sign:

1.0.0+build.18452

Under Semantic Versioning, build metadata does not change version precedence.

Calendar versioning

Calendar versioning uses release dates or date-derived components:

2026.07
2026.07.1
26.7
2026.7.29

Calendar versions communicate release timing more directly but do not necessarily indicate API compatibility.

Internal and marketing versions

A product may have several identifiers:

• an internal build number;
• a public version number;
• a marketing name;
• a protocol version;
• a package version; and
• a platform-specific store version.

Release documentation should make clear how these identifiers correspond.

Release models

Feature-based releases

A feature-based release is published after a planned set of functionality is completed. The date may move if required features or quality criteria are not ready.

Advantages may include:

• a coherent feature set;
• milestone-driven planning; and
• clear product themes.

Disadvantages may include:

• unpredictable dates;
• large integration periods;
• delayed completed work; and
• pressure to reduce testing when schedules slip.

Time-based releases

A time-based release is published according to a recurring schedule. Features that miss a cutoff move to a later release.

Python adopted an annual feature-release schedule beginning with Python 3.9, with alpha, beta, release-candidate and final milestones arranged around a predictable yearly cadence.

Time-based releases can provide:

• predictable planning;
• regular feedback;
• smaller change sets;
• clearer dependency scheduling; and
• reduced pressure to include incomplete features.

They may also require strict feature cutoffs and disciplined branch management.

Rolling release

A rolling release receives updates continuously rather than being replaced by occasional large versions. Users move through an ongoing stream of package updates.

A rolling model may still use:

• snapshots;
• repository channels;
• package versions;
• installation images;
• security advisories; and
• compatibility milestones.

Rolling release does not mean that every update is installed immediately or that all packages are always at their newest upstream versions.

Continuous delivery

Continuous delivery is a practice in which changes are built, tested and kept in a deployable condition. A release decision may still require manual approval.

Continuous deployment

Continuous deployment automatically deploys changes that satisfy the defined pipeline and policy requirements.

Continuous models may use:

• feature flags;
• progressive delivery;
• automated tests;
• deployment gates;
• canary groups;
• observability;
• rollback automation; and
• small incremental changes.

Even when deployment is continuous, organizations may still publish versioned client applications, APIs, release notes or compatibility milestones.

Staged rollout

A staged rollout distributes a release to increasingly large groups rather than to all users at once.

A rollout may progress through:

1. internal users;
2. volunteer testers;
3. a small percentage of production users;
4. selected regions or devices;
5. a larger production percentage; and
6. general availability.

Staged rollout can limit the impact of regressions and allow real-world monitoring before broad deployment.

Canary release

A canary release exposes a change to a small group or environment before wider deployment. The name refers to the historical use of canaries as early warning indicators.

Canary releases may be selected by:

• account;
• device;
• geographic region;
• server cluster;
• organization;
• random percentage;
• opt-in setting; or
• internal employee group.

A canary channel may also refer to a continuously updated early-access product build, as in Chromium's release-channel system.

Release preparation

A formal release process may include the following activities.

Planning

Release planning defines:

• scope;
• supported platforms;
• compatibility requirements;
• schedule;
• quality criteria;
• security requirements;
• documentation requirements;
• responsible personnel;
• distribution channels; and
• rollback plans.

Branching and feature freeze

A project may create a release branch separate from active development. A feature freeze limits or prohibits new functionality so the team can concentrate on stabilization.

A freeze may apply to:

• new features;
• user-interface strings;
• APIs;
• database schemas;
• dependencies;
• documentation structure; or
• all changes except approved defect corrections.

Building and packaging

Release artifacts should be created through a controlled process using known source revisions, dependencies, compilers and configuration.

Packaging may produce different artifacts for:

• operating systems;
• processor architectures;
• package managers;
• container registries;
• application stores;
• cloud environments; and
• hardware devices.

Verification

Release verification may include:

• unit tests;
• integration tests;
• system tests;
• regression tests;
• performance tests;
• security testing;
• accessibility testing;
• compatibility testing;
• installation tests;
• upgrade and rollback tests;
• disaster-recovery tests; and
• manual acceptance review.

Release notes

Release notes commonly identify:

• new features;
• behavior changes;
• corrected defects;
• security fixes;
• known problems;
• deprecated features;
• removed functionality;
• supported upgrade paths;
• system requirements; and
• acknowledgments.

GitHub allows releases to be associated with repository tags, descriptions and downloadable assets, and can generate release-note content from repository changes.

Signing and integrity

Publishers may provide:

• cryptographic signatures;
• signed source-control tags;
• checksums;
• transparency-log entries;
• build attestations;
• provenance records; and
• software bills of materials.

These records can help users confirm that downloaded artifacts are authentic and unchanged.

GitHub describes an immutable release as one whose associated assets and tag cannot be altered after publication, reducing the opportunity to replace established artifacts with malicious or incompatible files.

Publication

Publication may involve:

• creating or signing a version tag;
• uploading packages;
• promoting container images;
• submitting applications to stores;
• updating package repositories;
• publishing documentation;
• announcing availability;
• enabling update services; and
• updating support records.

Monitoring

After publication, teams may monitor:

• installation success;
• crash reports;
• application errors;
• performance;
• security events;
• support requests;
• user feedback;
• rollback rates;
• adoption; and
• service health.

A release may be paused, withdrawn or replaced when monitoring reveals a significant regression.

Release withdrawal and rollback

A publisher may withdraw a release because of:

• data corruption;
• security vulnerabilities;
• installation failures;
• severe regressions;
• licensing problems;
• incorrect packaging;
• broken digital signatures;
• incompatible migrations; or
• inaccurate release artifacts.

Withdrawal may involve removing downloads, stopping automatic updates, revoking signatures or publishing a replacement.

A rollback restores an earlier known-good version. Rollback may be difficult when a release changes stored data, database schemas, network protocols or external dependencies.

Release plans should therefore define:

• whether rollback is supported;
• what data must be backed up;
• whether migrations are reversible;
• how long the rollback window remains open; and
• what happens to data created by the new version.

Compatibility

Release policies may address several forms of compatibility:

Backward compatibility

A newer version can use data, interfaces or integrations created for an older version.

Forward compatibility

An older component can tolerate data or behavior produced by a newer version, usually within defined limits.

Source compatibility

Existing source code can be compiled or interpreted against the new version without modification.

Binary compatibility

Previously compiled software can continue operating with the new version.

Protocol compatibility

Components using different versions can communicate successfully.

Data compatibility

Stored information can be read and preserved across upgrades.

A release labeled stable does not automatically guarantee every type of compatibility.

Examples of release systems

Examples of documented release approaches

Project or publisher	Documented model	Notable terminology
Python	Scheduled feature-release cycle followed by maintenance and security periods	Alpha, beta, release candidate and final
Chromium and Chrome	Channel-based promotion	Canary, Dev, Beta and Stable
Semantic Versioning	Version-numbering specification for declared public APIs	Major, minor, patch and pre-release identifiers
GitHub repositories	Tagged releases with notes and downloadable assets	Draft, pre-release, latest release and immutable release
Microsoft products and services	Product-specific support policies	Fixed Lifecycle and Modern Lifecycle

The examples illustrate that release stages, distribution channels, version numbering and support life cycles are related but separate systems.

Relationship to other life cycles

Software development life cycle

The software development life cycle covers the wider process of planning, designing, implementing, testing, operating, maintaining and retiring software. A development project can contain many individual release life cycles.

Product life cycle

A product life cycle may include market introduction, adoption, growth, commercial maturity and withdrawal. These business stages do not necessarily correspond to technical release labels.

Support life cycle

A support life cycle defines how long users receive updates and assistance. It may begin at general availability and continue across mainstream, extended, security-only or paid-support phases.

Vulnerability life cycle

A vulnerability life cycle may include discovery, reporting, coordination, correction, disclosure and deployment of security updates. It can span several software releases.

Common misconceptions

Stable means defect-free

Stable software can still contain known and unknown defects. The label generally indicates intended production use and controlled change, not perfection.

Beta always means feature-complete

Some projects freeze features at beta, while others continue adding or changing them. The publisher's documentation determines the meaning.

Version 1.0 is always the first usable version

Some projects remain below version 1.0 while being widely used. Others begin with a larger number or a calendar-based identifier. Version numbering is a project convention.

Release candidate means final release

A release candidate is only a candidate. A blocking defect may require another candidate or a postponed release.

General availability means every user receives the release immediately

A generally available product may still use phased deployment, regional availability or update rings.

End of life means the software stops running

End-of-life software may continue to operate, but support, security updates and compatibility commitments may have ended.

Open source means permanent maintenance

Public source code allows others to inspect or continue a project, but it does not guarantee that the original maintainers or any replacement group will provide ongoing support.

See also

• Software development life cycle
• Software versioning
• Semantic Versioning
• Release management
• Continuous integration
• Continuous delivery
• Continuous deployment
• Rolling release
• Long-term support
• End-of-life product
• Patch (computing)
• Software maintenance
• Software testing
• Alpha testing
• Beta testing
• Release candidate
• Version control
• Build automation
• Software supply chain

External links

• Python release terminology
• Python annual release cycle
• Chromium release channels
• Semantic Versioning specification
• GitHub release documentation
• Microsoft Lifecycle Policy
• NIST software-development life-cycle definition
• NIST Secure Software Development Framework