Skip to the desired schema changes

The Release Catalog should be thought of as a series of Lifecycle events around Version releases made by Committees on their Projects. Each release consists of a version, metadata, and artifacts. Life cycle events as defined here:

https://ecma-tc54.github.io/ECMA-xxx-CLE/#sec-event-types

• released (version) - A release is finished event.
• endOfDevelopment (versions) - Manual event.
• endOfSupport (versions) - Manual event.
• endOfLife (versions) - Manual event.
• endOfDistribution (versions) - One or more release is archived.
• endOfMarketing (versions) - I think that we don't need this event.
• supersededBy (versions) - Manual event (do we need this?)
• componentRenamed (versions) - Manual event (do we need this?)
• withdrawn (event) - Manual.
• Consider adding vulnerabilityAnnouncement event to connect CVE version specific lifecycle events.

If we choose to follow this standard then we will need to add a support policy for products that is supposed to be immutable(?) We can specify a default policy that is essentially when the PMC or Foundation decides to end a Project version we will for one of several reasons. If we want to allow a PMC project specific support policy then we can override, but the PMC will need to be compliant with their own policy without expecting ATR to enforce it.

The following views / cards / endpoints should be available from the catalog.

1. Latest release. Return the release with the "largest" version that is current. Could have a version mask to find the latest 1.2.* when multiple major versions are still being released.
2. Current releases. Return a list of all releases with active versions sorted by recency.
3. Lifecycle events. Return the history of all of a project's releases in the order described by the standard.
4. Version results. Return the history of events related to specific versions.