-
Notifications
You must be signed in to change notification settings - Fork 1
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
RFC: Initial Draft #1
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,143 @@ | ||
# releases.json | ||
|
||
A specification for the releases.json data format. | ||
|
||
## Introduction | ||
|
||
This specification documents the `releases.json` file format, which is intended to be used by vendors to publish | ||
information about various releases of the artifacts produced by them. | ||
|
||
## Terms | ||
|
||
**Product**: is an artifact produced by the vendor, typically a software or device. | ||
|
||
**Release**: is a singular release made for a product. It is identified by its version string, which is specified without any `v` prefix. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. without any |
||
|
||
**Release Cycle**: is a group of releases, typically grouped by their compatibility or closeness in variations. | ||
|
||
**Support**: The expectation of receiving timely bug fixes for any defects in the product. | ||
|
||
**Security Support**: The expectation of receiving security fixes (such as fixes for CVEs, security announcements etc) for a product. | ||
|
||
**End-of-Life**: When a product reaches End-of-Life, no further updates are expected, including security fixes. | ||
|
||
**Commercial Support**: Expectation of receiving fixes from a vendor on payment to a vendor - not necessarily first-party. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Difficult to understand. Maybe something like:
|
||
|
||
**Long-Term-Support**: A Long-Term-Support release cycle is expected to be maintained for a longer time period than usual releases. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Long-Term-Support" -> "Long-Term Support". |
||
|
||
**Active Support**: When a specific release cycle gets active development, for both bug fixes as well as feature development. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Definitions of levels of support could grouped and sorted "chronologically" :
Supported Release could be move next to Support. |
||
|
||
**Supported Release**: A release under a Release Cycle that has not yet reached End-of-Life. | ||
|
||
## Specification | ||
|
||
The releases.json file is expected to be located at `/.well-known/releases.json` on the primary website of the vendor. | ||
In case the primary website is a source-code repository, a top-level releases.json file can also be used in the repository. | ||
To delegate updates to this file, a 302 redirect can be configured, and should be supported by any clients. | ||
|
||
### Keys | ||
|
||
``` | ||
# A list of various products offered by the vendor | ||
products: [ | ||
// An array of products | ||
// each specified as under. | ||
], | ||
// TODO: Decide Vendor/Supplier/....? | ||
vendor: { | ||
// TODO | ||
} | ||
``` | ||
|
||
### Product Specification | ||
|
||
```json5 | ||
{ | ||
name: "Product Name", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will we have to rename |
||
// URL for the product, where more information can be found. | ||
// Optional | ||
url: "" | ||
// TODO: Specify this properly | ||
// Optional | ||
vcs: "", | ||
# URL where more information about the support policy can be found. | ||
// Optional | ||
policyURL: "https://example.com/support-information", | ||
// A list of supported versions, which is as per the `eol` dates. | ||
// This must match one of the latestVersion | ||
// TODO: Decide between supportedVersions or supportedReleases | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
// Mandatory | ||
supportedReleases: [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If think we should only have This way the vendor could only say it supports some cycle without specifying the version (which is even lighter / less work for him). For example: releaseCycles: [
{
"id": "5.2",
"supported": true
}
] IMHO endoflife.date is more about release cycles than individual versions (at least in its current form). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This moves the burden of "whether a version is supported or not" to the scanner, and is highly dependent on how you do matching - it will be prone to bugs and confusion. Using endoflife.date is definitely about releaseCycles, but not every software fits neatly into it (see windows versions for eg). SupportedReleases is something that fits everywhere, and is much simpler to use - both for publishers as well as consumers. While endoflife.date project will benefit from releaseCycles, that is not something the ecosystem really asks for - we're asking for it to make our lives easier. What the world needs is "is my version in a list of supported versions". |
||
"5.2.3", | ||
"4.3.17" | ||
], | ||
// Optional | ||
releaseCycles: [ | ||
{ | ||
// Release Cycle Identifier | ||
id: "5.2", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Name is not enough ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Name should be human readable (similar to how we use |
||
// Other alternative idenfiers for this release cycle. | ||
// Helpful especially, when the product is distributed via alternative channels | ||
// and different identifiers are used across channels (such as platforms, countries etc). | ||
variants: ["05.2"], | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do you have an example you can share here around variants usage? |
||
name: "5.2", | ||
// Long-term-support = true/false/YYYY-MM-DD | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Having fields that can have multiple may types be complex in some languages. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We use However, given that both JSON schema and openAPI schema specification support alternative types for a JSON object, it should be okay. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would have to agree that fields should always be a single type. It can complicate data validation and can be difficult in strongly typed languages like golang. |
||
// Use a date, if the release "enters" LTS on a specific date. | ||
// default: false | ||
lts: true, | ||
// optional, must belong to the release cycle. | ||
codename: "dragon", | ||
// Valid date in YYYY-MM-DD format | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ISO 8601 date format (https://www.iso.org/iso-8601-date-and-time-format.html). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 |
||
// In case the release was staggered over time, the date of first | ||
// release should be used. | ||
releaseDate: 2022-04-01, | ||
// Latest version of the product under this release cycle | ||
latestVersion: "5.2.3", | ||
latestReleaseDate: 2022-12-16, | ||
// TODO: This is new, to provide separate links for both. | ||
link: "https://example.com/5.2", | ||
// A link where more information can be found about the latest version | ||
// This could be a changelog, or release notes, or the announcement URL | ||
latestLink: "https://example.com/5.2.3", | ||
// The EOL field denotes a release cycle as end-of-life | ||
// If the EOL was reached on a specific date, use YYYY-MM-DD | ||
// If the eol date is unavailable, but product is EOL, use true | ||
// Otherwise, set to false. | ||
// eol: true, | ||
// eol: false | ||
eol: 2024-12-01, | ||
|
||
// TODO: Decide on available/discontinued naming | ||
// Whether this release is still published and made available | ||
// via a primary non-archive source. | ||
// For devices, this would imply the device is available in the market | ||
// for software products, they should be downloadable on the primary source. | ||
availability: true/false | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
// Support Variants. | ||
// TODO: Find better name, maybe "supportVariants"? | ||
plans: { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be an array ? Is there a lot of products having multiple support plans ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe we should drop eol/lts etc from the releaseCycle, and only keep it inside plans. And specify a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It makes thing more complex IMHO. Do you think it is frequent to have multiple "plans" for the same product ? Maybe a concrete example would help us see things more clearly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Keeping one top-level object for date/EOL data, and multiple sub-level ones will only make matching more complex. Having an array of plans will be more explicit, and easier for matching by scanners and others. Array: Used a dictionary here to provide an identifier for each plan. But can add a |
||
// Standard Keys that can be used here are: | ||
// 1. commercial | ||
// 2. extended | ||
// Non-standard keys can be used to denote separate plans. | ||
"commercial": { | ||
eol: , | ||
development: , | ||
lts: , | ||
name: "", | ||
// Optional | ||
latestVersion: "5.2.4", | ||
latestReleaseDate: 2022-12-16, | ||
releaseDate: | ||
} | ||
} | ||
|
||
// TODO: Find a better name | ||
// Whether active development is happening in this release cycle. | ||
// Use date for the last date of activeDevelopment. | ||
development: true/false/date | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Isn't it the current endoflife There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the current eol support field, but renamed to |
||
} | ||
] | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just an idea : we could group dates together, for example : "development": {
"active": true/false/date
"support": true/false/date
"security": true/false/date
"eol": true/false/date
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't get this one, why are we grouping this under |
||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
produced by them
->they produce