ERP.net evolves over time. This sometimes requires changes, some of which are reflected in the Domain API and the way it's used.
What is considered a breaking change?
Breaking change is any change that requires you to make an adjustment or correction in your external application (or Domain API "user" in general). Examples of these are:
- Removal of entities.
- Removal of attributes, part of an entity. E.g, data attributes, references, child collections.
- Altering the aggregate tree for an entity*.
* This doesn't necessarily lead to a direct breaking change, but is often an indicator of this.
Depreciation. Non-breaking changes (but a strong indicator of forthcoming ones)
There are situations where, for example, removing an attribute in an entity will not be done immediately, but will initially be marked as "Obsolete".
What should I consider when something is "obsolete"?
1. First of all, there is a good reason for this.
2. You have to take a different approach to your task.
3. Obsolete fields may be completely removed in the next new version.
How do I know I'm using something that is obsolete?
From our documentation.
The obsolete attributes will be marked as such.
Additionally, when you make a wildcard (*) and "DEFAULT" select, they will not be included in the result. You have to specify them explicitly.
An example of this, starting with version 2022, is IsReleased in Crm.SalesOrders.SalesOrder.
If you do:
GET ~/Crm_Sales_SalesOrders(33cd6cb9-0f43-df11-a1e1-0018f3790817)?$select=DEFAULT
The IsReleased attribute won't be included. To see it, you need to do this:
GET ~/Crm_Sales_SalesOrders(33cd6cb9-0f43-df11-a1e1-0018f3790817)?$select=DEFAULT,IsReleased
New stuff
These are the addition of new entities, new attributes and so. This is not considered as a breaking change.
Communication & feedback
We'll notify you of breaking changes in advance, so you can take care and adapt to these changes.
0 Comments