Skip to content

Document how to work with experimental event types #335

@magnusbaeck

Description

@magnusbaeck

Description

At the Oct 2022 summit we discussed deployment events and the suggestion was made to start with an experimental v0 version of the proposed EiffelArtifactDeployedEvent (see #322). If we decide to do this there are few practical matters that aren't obvious and therefore should be documented:

  • What's the first version of an experimental event? 0.0.1 or 0.1.0 or something else?
  • Are we allowed to make any kind of backwards incompatible changes within the v0 line? If so, how should SDKs handle the event versions? For normal non-experimental versions we can use the same data type for all event versions that share a major version because changes will always be forward compatible, but if that no longer is true we can't assume that a particular data type can be used for both, say, 0.1.0 and 0.2.0 of en event.
  • ...

Motivation

If we're going to introduce such a concept we should document how it should be used so that we can be consistent. Documenting things also forces us to really think things through.

Exemplification

As a maintainer of eiffelevents-sdk-go I'd like to know if and how the experimental events will affect how I generate the SDK, or how the SDK can be used by clients.

Benefits

Less ambiguity.

Possible Drawbacks

None.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions