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

RFC: Initial Draft #1

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
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
143 changes: 143 additions & 0 deletions README.md
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.
Copy link
Member

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


## 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.
Copy link
Member

Choose a reason for hiding this comment

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

a singular -> a single

Copy link
Member

Choose a reason for hiding this comment

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

without any v prefix -> without any prefix (such as v) or suffix (such as -final).


**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.
Copy link
Member

Choose a reason for hiding this comment

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

Difficult to understand. Maybe something like:

expectation of receiving fixes in return for payment - not necessarily from the original vendor.


**Long-Term-Support**: A Long-Term-Support release cycle is expected to be maintained for a longer time period than usual releases.
Copy link
Member

Choose a reason for hiding this comment

The 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.
Copy link
Member

Choose a reason for hiding this comment

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

Definitions of levels of support could grouped and sorted "chronologically" :

  • Active Support
  • Security Support
  • Long-Term-Support
  • Commercial Support
  • End-of-Life

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",
Copy link
Member

Choose a reason for hiding this comment

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

Will we have to rename title to name in products front matter (note: page.name is already a default property of pages : https://github.com/jekyll/jekyll/blob/master/lib/jekyll/page.rb#L8) ?

// 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
Copy link
Member

Choose a reason for hiding this comment

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

supportedReleases would make sense given the definitions above. version may be more common though.

// Mandatory
supportedReleases: [
Copy link
Member

@marcwrobel marcwrobel Dec 19, 2022

Choose a reason for hiding this comment

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

If think we should only have releaseCycles and make most of the fields in releaseCycles optional.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The 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 supportedReleases shifts that back to the vendor, by being explicit about the latest and supported releases.

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",
Copy link
Member

Choose a reason for hiding this comment

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

Name is not enough ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Name should be human readable (similar to how we use releaseLabel), while id should be friendly to version matching.

// 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"],
Copy link

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

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

We use bool/date as a common data type, and while JSON will support this, it might not work in all languages easily. One option is to split each such field into two, say eolStatus, and eolDate instead of eol.

However, given that both JSON schema and openAPI schema specification support alternative types for a JSON object, it should be okay.

Copy link

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

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

discontinued may be more explicit.


// Support Variants.
// TODO: Find better name, maybe "supportVariants"?
plans: {
Copy link
Member

Choose a reason for hiding this comment

The 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 ?

Copy link
Member Author

Choose a reason for hiding this comment

The 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 default plan

Copy link
Member

@marcwrobel marcwrobel Dec 28, 2022

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The 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 id field instead.

// 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
Copy link
Member

Choose a reason for hiding this comment

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

Isn't it the current endoflife support field ? If no I think we should add the support field too.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is the current eol support field, but renamed to development for clarity (This release cycle sees active development - new features, bug fixes etc)

}
]
}
Copy link
Member

Choose a reason for hiding this comment

The 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
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Don't get this one, why are we grouping this under development?

```