Planned Breaking Changes in Commerce 2017
We are working on a number of changes in Commerce that will change some behavior and APIs in a way that by Semantic Versioning is considered breaking and therefore will be released as a new major version of Commerce. The current estimate for this new major version is Q2 2017.
Details on the breaking changes will be announced at a later stage when we have a more exact feature set defined for this release. Here is a list of some candidates we are considering. As usual, all this information his is subject to change.
Improving Entry Sort Order on Categories
The SortOrder of NodeEntryRelations is currently used to determine catalog entries' home category (ParentLink in the Content model for catalog content). This makes it hard to use SortOrder for defining the actual order of entries in a category. We will introduce a separate way of defining the home category, creating a clearly defined use for sort order. This will enable us to add the feature of working with sort orders in the Catalog UI to control the way categories are displayed in the site implementation.
Reworked Catalog Import
In addition to the change in behavior of SortOrder and a new element for defining the home category in the catalog XML itself, we will initiate some long overdue code improvements of the Catalog import. While this is mostly under the hood, it requires us to change the public API of the catalog import.
Improved API usability for IRelationRepository
The terminology of Source/Target for relations has been a source of much confusion and the target of much criticism. It will be superseded by a Parent/Child model (the old model will like remain but be marked as obsolete).
Order Calculator Changes
Some default calculator implementations don't work as expected, for example they include order level discounts in the subtotal instead of the order total.
Removing Legacy APIs and Components
- Remove the legacy Asset system.
- Rework/remove the dependency from payment providers to nSoftware.
- Make the "VNext" workflows the default and require configuration to use the old Promotion system, and deprecate it.
- Possibly remove concept of ApplicationId available on many APIs, since it is rarely used and does not have full support throughout the platform anyway.
Clean Up Previously Deprecated APIs
There are a number of APIs that have been marked as obsolete for a long time, and will now be removed.
Good stuff!
You should also consider making overloads available that don't require a Market-parameter (for instance on IPriceService) to make single market solutions simpler. Sortof as with ApplicationId.
Suggestion noted! We are trying to keep the scope small to get it released rather than putting everything we want to do in there. Your suggestion seems like something we should be able to do without breaking changes using extension methods. I know you're not a fan of that because it makes mocking harder. But it is a tradeoff between mocking and implementing (real or stub), and I would argue that it is even a tradeoff in mocking. There will be less methods to mock and the extension methods should be thin enough to make it possible to easily mock the underlying interface method, e.g. an extension method with no MarketId parameter would pass MarketId.Empty to the underlying interface, so you just mock for that.
Agree with Magnus here..
Looks great! I really like that you are continuously revising the APIs and not just adding new features like some other CMSs I could name. I know how hard that can be to accept for some. It will make Episerver even stronger in the future...