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.

Sign up for GitHub

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

Jump to bottom

Release lifecycle marking #225

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft

Release lifecycle marking #225

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
9c52399
Release lifecycle marking
akubik-splunk Mar 30, 2023
e3d8c5c
Update specification/versioning.md
akubik-splunk Mar 30, 2023
85a4fd3
Update specification/versioning.md
akubik-splunk Mar 30, 2023
414b731
Updates after review
akubik-splunk Apr 4, 2023
2fb616a
Merge branch 'versioning-release-status' of https://github.com/signal…
akubik-splunk Apr 4, 2023
4e4af47
md lint fixes
akubik-splunk Apr 4, 2023
866050d
Merge branch 'main' into versioning-release-status
akubik-splunk Apr 4, 2023
1f17e86
Update specification/templates/CHANGELOG.md
akubik-splunk Apr 6, 2023
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
2 changes: 2 additions & 0 deletions specification/templates/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,8 @@ and this repository adheres to [Semantic Versioning](https://semver.org/spec/v2.

## Version 0.1.0 - 2021-04-01

Status: **Deprecated** (End of Support expected on 2024-04-01)

### General

- This release marks the first release of the repository.
Expand Down
32 changes: 32 additions & 0 deletions specification/versioning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,3 +77,35 @@ until the end of that component’s existence:
MUST be provided as the latest `PATCH` version for the latest `MINOR` version
of the latest `MAJOR` and SHOULD NOT be provided for previous `PATCH` or
`MINOR` releases.

## Release life cycle management
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about moving this to a separate file specification/releases.md. It would be more obvious that versioning.md is about versioning of the specification and release.md is about requirements connected with releases.

If you agree, please remember to add a - [Releases](specification/releases.md) in README.md.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this idea once we've approved the content.


Each repository `MUST` use [GitHub releases mechanism](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)
to create a versioned snapshot of components and features
pellared marked this conversation as resolved.
Show resolved Hide resolved
delivered to the users. If the release is also distributed via other
distribution channels (e.g. CDN, Registries, AppStores) it `MUST` state
its life cycle status according to following rules by any means available
in the given software distribution solution.

Each release `MUST` clearly state the life cycle
status and described as: Supported, Deprecated, End of Support.
pellared marked this conversation as resolved.
Show resolved Hide resolved
At minimum the required information should be included in [CHAANGELOG.md](https://github.com/signalfx/gdi-specification/blob/main/specification/templates/CHANGELOG.md)
akubik-splunk marked this conversation as resolved.
Show resolved Hide resolved
and equivalent mechanism provided by system used for distributing software.

If new version is released previously released versions `MUST` be evaluated
according to stability guarantees and marked as:

- Latest release `SHOULD` be marked as **Supported** indicating that this is
version recommended to new and existing users
- If applicable latest release of previous `MAJOR` line that is still under
active development `MUST` be marked as **Supported** indicating that previous
`MAJOR` line is under active development and users not ready to adopt
latest `MAJOR` version may use previous versions.
- Release which was superseded by newer version, thus has entered deprecation
period `MUST` be marked as **Deprecated** and `MUST` indicated planned
end of support date. This indicates that users should plan for upgrade to
Comment on lines +105 to +106
Copy link
Contributor

@pellared pellared Apr 6, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have already a requirement how long it must be supported? If so can we define it? Otherwise it will be hard to adopt the specification.

What if the latest release fixes a security vulnerability? Shouldn't we immediately drop supported require a version bump?

one of supported versions before date given.
- Release which deprecation period has ended `MUST` be marked as
**End of support** and `MUST` indicate date on which the release was marked
as end of support. This indicates that support for given release is no longer
provided and the users should immediately upgrade to newer supported version.
Comment on lines +83 to +111
Copy link
Contributor

@pellared pellared Apr 6, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some nit changes, remove some IMO unnecessary sentences or wording, I tried to restructure it a little to make it easier to read and validate when adopting the spec.

Suggested change
Each repository `MUST` use [GitHub releases mechanism](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)
to create a versioned snapshot of components and features
delivered to the users. If the release is also distributed via other
distribution channels (e.g. CDN, Registries, AppStores) it `MUST` state
its life cycle status according to following rules by any means available
in the given software distribution solution.
Each release `MUST` clearly state the life cycle
status and described as: Supported, Deprecated, End of Support.
At minimum the required information should be included in [CHAANGELOG.md](https://github.com/signalfx/gdi-specification/blob/main/specification/templates/CHANGELOG.md)
and equivalent mechanism provided by system used for distributing software.
If new version is released previously released versions `MUST` be evaluated
according to stability guarantees and marked as:
- Latest release `SHOULD` be marked as **Supported** indicating that this is
version recommended to new and existing users
- If applicable latest release of previous `MAJOR` line that is still under
active development `MUST` be marked as **Supported** indicating that previous
`MAJOR` line is under active development and users not ready to adopt
latest `MAJOR` version may use previous versions.
- Release which was superseded by newer version, thus has entered deprecation
period `MUST` be marked as **Deprecated** and `MUST` indicated planned
end of support date. This indicates that users should plan for upgrade to
one of supported versions before date given.
- Release which deprecation period has ended `MUST` be marked as
**End of support** and `MUST` indicate date on which the release was marked
as end of support. This indicates that support for given release is no longer
provided and the users should immediately upgrade to newer supported version.
Each release MUST clearly state the life cycle
status and described as one of:
**Supported**, **Deprecated**, **End of Support**.
Each repository MUST use [GitHub releases mechanism](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)
to publish versioned artifacts of components
delivered to the users.
The release the life cycle status MUST be included
in [CHANGELOG.md](templates/CHANGELOG.md).
When the component is also distributed via other channels
(e.g. CDN, Registries, AppStores) it MUST state
its life cycle status according to following rules by any means available
in the given software distribution solution.
When a new version is released it MUST be marked as **Supported**,
and all previously released versions MUST be evaluated
according to stability guarantees and marked as:
- If applicable latest release of previous `MAJOR` line that is still under
active development MUST remain as **Supported** indicating that previous
`MAJOR` line is under active development and users not ready to adopt
the latest `MAJOR` version may use previous versions.
- Release which was superseded by newer version, thus has entered deprecation
period `MUST` be marked as **Deprecated** and MUST indicated planned
end of support date. This indicates that users should plan for upgrade to
one of supported versions before date given.
- Release which deprecation period has ended MUST be marked as
**End of support** and MUST indicate date on which the release was marked
as end of support. This indicates that support for given release is no longer
provided and the users should immediately upgrade to newer supported version.