Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LTS #799

Merged
merged 4 commits into from
Jan 31, 2024
Merged

LTS #799

Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions concepts/0799-long-term-support/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# 0799 Aries Long Term Support Releases
- Authors: [Sam Curren]([email protected])
- Status: [PROPOSED](/README.md#proposed)
- Since: 2023-11-07
- Start Date: 2023-11-07
- Tags: [concept](/tags.md#concept)

Long Term Support Releases of Aries projects will assist those using the software to integrate within their development processes.

## Motivation

Long Term Support releases allow stable use of projects without frequent code updates. Designating LTS releases frees projects to develop features without worry of disrupting those seeking feature stable deployments.

## Project LTS Releases
- Details specific to each project will be found within the relevant repositories.
- Projects SHOULD create an LTS policy within the code repository for the project.
- Projects MAY alter any of these suggestions to match the needs of the project.

## LTS Release Tagging

- No Specific version number scheme for LTS releases are set Aries-wide. Each project can use any version numbering they desire. Projects must have a way to indicate patch releases.
- The README.md file within each repository must indicate which version is an LTS release, with a link to the release or branch of the LTS
- Each LTS release MUST include detailed release notes detailing the changes from the last LTS release, including complex details or gotchas.
- It is recommended, when possible, to designate an LTS release when a project reaches compliance with an Interop Profile, including an AIP.

## LTS Support Timeline

- Each LTS release MUST be supported for at least 9 months AFTER the next LTS release is designated.
- When the next LTS release is designated, the prior LTS release must clearly indicate the End of Support Date at least 9 months in future.
- A branch SHOULD be created to ease bugfixes and the maintenance of LTS patch releases.
- If a support term in excess of the minimum 9 months is chosen and and End of Support Date published, that period MUST be honored for that release.
- Projects may may designate an LTS release with any candance desired by the project.
- Frequent LTS relases may result in multiple LTS releases receiving support. Seeking community input for LTS release timing may decrease support efforts.

## LTS Release Updates

- Each LTS release MUST be updated for security updates via patch releases for the duration of its support lifetime.
- Each LTS release MAY include bugfixes that impact usability of the release.
- LTS patch releases MUST include detailed release notes.
- Updates MUST NOT include API updates, programatic interface changes, or major logic changes.

## References
This policy is inspired by the Fabric LTS Policy https://hyperledger.github.io/fabric-rfcs/text/0005-lts-release-strategy.html

Loading