Introduce a roadmap for Lifecycle-Manager API versions

[Tomasz-Smelcerz-SAP]

Description

We need a plan for future API releases to manage our API in a proper way: ensuring backwards-compatibility, smooth API migration etc.
The map must include all our Kinds (Kymas, ModuleTemplates, Manifests, etc) - or, perhaps, we need a separate "path" for every Kind in the map.
The goal is to have a plan for when we introduce certain API feature (like a new attribute) and when we plan to deprecate it or remove it. We need a similar plan for the API versions.

Reasons

Because we introduce new features and deprecate/remove the old ones, a careful plan for introducing/executing these changes on the API level is necessary.

This is important because we're dealing with multiple attributes from multiple features, spanning multiple Kinds. Sometimes having mutual dependencies. Ensuring the correct lifecycle, without breaking backward-compatibility and giving users enough time to migrate, requires usage of multiple API versions. Then we have to manage the lifecycle of these versions correctly.

In principle, if we consider just a single attribute, we should be able to tell "when" (in which API version) this attribute is:

• introduced
• deprecated
• removed from the API

For the API versions, we must be able to tell when:

• a version is released (probably linked to LM release)
• a version is deprecated
• a version is no-longer-served

The "roadmap" allows us to plan ahead and find out when we should release a new API version, when we should deprecate it and when we should remove it from environments (no-longer-served). And of course the plan tells what is included in (removed from) ever planned API version.

Acceptance Criteria

• Come up with idea for the map (Mural? something on Github?)
• Try to create the initial map using our current API versions.

Feature Testing

No response

Testing approach

No response

Attachments

No response