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

docs: document version and deprecation policy #1279

Merged
merged 1 commit into from
Jul 21, 2023
Merged
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
36 changes: 36 additions & 0 deletions docs/reference/versions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
title: "Versions"
layout: default
sort: 8
---

# Versions and deprecation
{: .no_toc}

---

## Supported versions

Node Feature Discovery follows [semantic versioning](https://semver.org/) where
the version number consists of three components, i.e. **MAJOR.MINOR.PATCH**.

The most recent two minor releases (or release branches) of Node Feature
Discovery are supported. That is, with X being the latest release, **X** and **X-1**
are supported and **X-1** reaches end-of-life when **X+1** is released.

## Deprecation policy
Copy link
Contributor

@adrianchiris adrianchiris Jul 23, 2023

Choose a reason for hiding this comment

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

will you call out any deprecation in release notes ?

e.g another section in release notes (after the "Whats Chaged") section
or in the same section but the PR title be in a specific format like: [DEPRECATE] mark feature FOO as deprecated so that it "pops out" in release notes ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will you call out any deprecation in release notes ?

e.g another section in release notes (after the "Whats Chaged") section or in the same section but the PR title be in a specific format like: [DEPRECATE] mark feature FOO as deprecated so that it "pops out" in release notes ?

Yes, definitely. We've already had a "Deprecations" section under Changelog/What's new in the past few releases (e.g. v0.13.0. Maybe deprecations should/could be a separate main section to spot that more easily, dunno 🧐 We can discuss this when writing release notes for v0.14.0 (or you can comment it there already if you have opinions on that).

Good suggestion about the PR titles. We could add some style-guide/best-practices/contrib-guidelines e.g. in docs/contributing/ or somewhere. Feel free to help with that 😉


### Feature labels

Built-in [feature labels](../usage/features.md) and
[features](../usage/customization-guide.html#available-features) are supported
for 2 releases after being deprecated, at minimum. That is, if a feature label
is deprecated in version **X**, it will be supported in **X+1** and **X+2** and
may be dropped in **X+3**.

### Configuration options

Command-line flags and configuration file options are supported for 1 more
Copy link
Contributor

Choose a reason for hiding this comment

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

any relations to helm values / operator (CR) values ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point @adrianchiris.

Regarding Helm charts '#1283

Regarding the operator we need to handle that separately because it's maintained in a separate repo:
kubernetes-sigs/node-feature-discovery-operator#198

release after being deprecated, at minimum. That is, if option/flag is
deprecated in version **X**, it will be supported in **X+1** and may be removed
in **X+2**.