You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
It should be ok to link to an experimental event type from an existing event type. Minor version stepping as usual when adding such a link type, with a note saying "This is a link to an experimental event type which might be removed in a later version".
If removing such a link to an experimental event type we should step the major version as usual.
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:
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.
The text was updated successfully, but these errors were encountered: