Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "MicroProfile/BreakingChanges"

(Document the process how to communicate breaking changes)
 
m (Clarify what's required around offering reverting of behaviour)
Line 1: Line 1:
This page lists what do you when a break change is introduced in a MP Spec.
+
This page lists what to do when a breaking change is introduced in a MicroProfile Specification.
  
 
== What is a breaking change ==
 
== What is a breaking change ==
Breaking changes mean backward incompatible changes, e.g. an API method was deleted or modified, etc. With a breaking change, microservices developed using old version of an API will cease to compile or result into behaviour change.
+
Breaking changes mean backward incompatible changes, e.g. an API method was deleted or modified, etc. With a breaking change, microservices developed using the old version of an API will cease to compile or result in behaviour changes.
  
  
 
== How can I handle the breaking change ==
 
== How can I handle the breaking change ==
If a breaking change is introduced in a MP spec, a subsection under release note must need to document what the breaking changes are. Ideally, if applicable, a solution needs to be provided for going back to the old behaviour.  
+
If a breaking change is introduced in a MP spec, a subsection within the release note must document what the breaking changes are, and what the migration path is.
  
For an instance, MicroProfile Metrics 2.0 changes @Counted(monotonic=true) to be @Counted, while the previous old behaviour of @Counted can be achieved via '@ConcurrentGauge`
+
It's up to individual specifications to determine if they want to provide a solution for reverting to the behaviour of the previous version.
 +
 
 +
For an instance, MicroProfile Metrics 2.0 changes @Counted(monotonic=true) to be @Counted, while the previous old behaviour of @Counted can be achieved via '@ConcurrentGauge`.

Revision as of 09:02, 3 May 2019

This page lists what to do when a breaking change is introduced in a MicroProfile Specification.

What is a breaking change

Breaking changes mean backward incompatible changes, e.g. an API method was deleted or modified, etc. With a breaking change, microservices developed using the old version of an API will cease to compile or result in behaviour changes.


How can I handle the breaking change

If a breaking change is introduced in a MP spec, a subsection within the release note must document what the breaking changes are, and what the migration path is.

It's up to individual specifications to determine if they want to provide a solution for reverting to the behaviour of the previous version.

For an instance, MicroProfile Metrics 2.0 changes @Counted(monotonic=true) to be @Counted, while the previous old behaviour of @Counted can be achieved via '@ConcurrentGauge`.

Back to the top