Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status: Investigating

Sponsor User: IBM

Date of Submission:  

Submitted by: Glen Darling

Affiliation(s): IBM

<Please fill out the above fields, and the Overview, Design and User Experience sections below for an initial review of the proposed feature.>

Scope and Signoff: (to be filled out by Chair)

Open Horizon should more completely support semantic versioning (semver). Currently oniy: "N", "N.N", and "N.N.N" semvers are supported.

...

I think we should fully support the current semver syntax, semver 2.0 (https://semver.org) for any resource types that have versions and are managed by Open Horizon through its REST APIs. Most especially this is needed for Services. Semver is ubiquitous in our industry and users have come to expect its flexibility so they are surprised when they see the restrictions in our limited implementation.

Design

Likely this would require multiple changes in the CLIs, APIs, file formats, and internal algorithms.

User Experience

Users often use the widely known semver syntax (e.g., "1.0.1.23" or "2.1.5-beta") only to have this rejected by Open Horizon.

...

(unknown – likely many)

Security

<Describe any related security aspects of the solution. Think about security of components interacting with each other, users interacting with the system, components interacting with external systems, permissions of users or components>

APIs

(none)

APIs

Likely there would be corresponding API changes.<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>

Build, Install, Packaging

<Describe any changes to the way any component of the system is built (e.g. agent packages, containers, etc), installed (operators, manual install, batch install, SDO), configured, and deployed (consider the hub and edge nodes).>(none)

Documentation Notes

<Describe the aspects of documentation that will be new/changed/updated. Be sure to indicate if this is new or changed doc, the impacted artifacts (e.g. technical doc, website, etc) and links to the related doc issue(s) in github.>

Test

This new feature would have to be documented, of course.

Test

This new feature would have to be tested, of course.<Summarize new automated tests that need to be added in support of this feature, and describe any special test requirements that you can foresee.>