RFC: Initial Draft #1
Conversation
| ## 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. |
There was a problem hiding this comment.
produced by them -> they produce
|
|
||
| **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. |
|
|
||
| **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.
without any v prefix -> without any prefix (such as v) or suffix (such as -final).
|
|
||
| **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.
Difficult to understand. Maybe something like:
expectation of receiving fixes in return for payment - not necessarily from the original vendor.
|
|
||
| **Commercial Support**: Expectation of receiving fixes from a vendor on payment to a vendor - not necessarily first-party. | ||
|
|
||
| **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.
"Long-Term-Support" -> "Long-Term Support".
| releaseCycles: [ | ||
| { | ||
| // Release Cycle Identifier | ||
| id: "5.2", |
There was a problem hiding this comment.
Name should be human readable (similar to how we use releaseLabel), while id should be friendly to version matching.
| // 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.
discontinued may be more explicit.
| // 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.
Isn't it the current endoflife support field ? If no I think we should add the support field too.
There was a problem hiding this comment.
This is the current eol support field, but renamed to development for clarity (This release cycle sees active development - new features, bug fixes etc)
|
|
||
| // Support Variants. | ||
| // TODO: Find better name, maybe "supportVariants"? | ||
| plans: { |
There was a problem hiding this comment.
Should this be an array ? Is there a lot of products having multiple support plans ?
There was a problem hiding this comment.
Maybe we should drop eol/lts etc from the releaseCycle, and only keep it inside plans. And specify a default plan
There was a problem hiding this comment.
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.
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.
| development: true/false/date | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
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.
Don't get this one, why are we grouping this under development?
| // This must match one of the latestVersion | ||
| // TODO: Decide between supportedVersions or supportedReleases | ||
| // Mandatory | ||
| supportedReleases: [ |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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".
|
Was looking at @witchcraze's EOL-Dataset: https://github.com/witchcraze/EOL-DataSet, which is trying something similar. notable differences:
It still has some of our shortcomings:
👋🏽 @witchcraze: It will be nice to hear your thoughts on this draft as well. |
|
Thank you for your mention, and sorry, I missed this. |
|
For now, let me comment about witchcraze/EOL-DataSet. Purpose of this project was rounghly notice for me of changing EOL of Software Collectino and AppStream of RedHat.
As you know, there are many version without EOL. Personally I do not like YYYY EOL and monthly range EOL. Sometimes, this project (and I) use forecast EOL.
Yes, strongly agree. As I wrote before, I think this is convenient in some cases. As I wrote before, I felt this project focus only upstream EOL, but if this project covers major downstream EOL, it will expand user's opinion. I'll try check related thred and Initial Draft later |
|
Sorry for my late. Let me write comment for draft. Terms
I felt this explanation is good for many cases. Someone will use EOL of OS/firmware update may come before EOL of providing hardware parts. If too much redundancy is allowed, I'll propose child items under or In this case, usable type is defined, and type will increase with schema version
As you commented, I think I'll propose adding This can show fork distributions as 1 product data. (OpenJDK, K8S, maybe RHEL, and so on) To cover explanation of supported scope, I'll propose using policyURL.
SpecificationMaybe definition of product is required. For example, elastic suites. KeysFor hardware, product, model, version, option(e.g. intel type. AMD type) maybe required to identify those eol, but I do not know detail. Product Specification
To check EOL and vulnerability, these url type will be useful.
If child items under I felt these versions would match But this shows |
Yes, that's the intent of the specification - provide a clear and easily published (static, not dynamic) machine readable document with product support information. Noting down issues and possible solutions: DatesSwitching to ISO8601 makes sense. It supports Dates/Datetimes/Approximate Dates ( Dealing with non-upstream productsI agree this is worth solving, and there is some consensus on this being downstream. If this specification works, we can use the Meaning of Support/EOL/...Clear problem - I think having sub-definitions (say like active-development, ticket-accepted, security-patches-available, patches-on-request), and then defining each plan as providing a subset of these is probably the cleanest approach. However, this then makes it much harder for third-parties to consume this data - there's no easy shortcuts, like picking Supporting forks/channel/downstream projects in same dataI would mark this as a non-goal. For eg, the OpenJDJ/Oracle Java/Azure JDK etc projects should all publish their own While other projects (such as endoflife.date) could collate this information and publish them together, and the specification already supports multiple products ( Unsure about providing plan level URLs, but don't see the harm in it. Defining ProductGood point Separate links to various pagesLinks often to go official-forum-post, blog, reports, articles, changelogs, source-code, release notes etc. Maybe we can define a dictionary of types, and add a generic
|
|
Will do a second draft considering the suggestions from here, and update soon. |
| // 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.
do you have an example you can share here around variants usage?
|
@captn3m0 @marcwrobel @noqcks |
Context
I've mentioned a plan for
releases.jsonin a few comments in the past:The intent has been for us to publish a specification to closely match our API, that can then be used by vendors to publish their own data in a machine-readable format. For most products, they can just set a redirect from their website to endoflife.date API till stay start publishing this.
RFC
This is a v0-draft, requesting feedback and comments. I've tried to keep our recommendations in mind, with the caveat that this is meant to be consumed by code - so we can be verbose.
Left a lot of TODOs in the specification, and haven't filled it around properly (missing values etc), but the intent should be clear for all fields.
Extensions:
Down the line, I can expect some extensions to make this more useful:
releases.json, but have this published over a dozen files across various teams.Alternatives
The current draft uses a top level
releaseCycleskey to keep the specification brief and easy to use. However, this might make it complicated to generate. I've kept only thesupportedReleasesfield mandatory to promote publishing anything over nothing.But an alternative would have been for this file to be more exhaustive and cover each version individually:
However, this might become extremely verbose, especially for products that have lots of versions. Release Cycles are a common enough abstraction that should apply to most cases. The advantage with this approach would have been the possible exhaustive list of versions, which would result in better matches against PURLs for eg.