Try our conversational search powered by Generative AI!

Magnus Rahl
Feb 27, 2017
(8 votes)

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.

Feb 27, 2017


Arve Systad
Arve Systad Feb 28, 2017 08:13 AM

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.

Magnus Rahl
Magnus Rahl Feb 28, 2017 09:45 AM

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.

valdis Feb 28, 2017 05:25 PM

Agree with Magnus here..

Mar 1, 2017 12:31 PM

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...

Please login to comment.
Latest blogs
Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog