Follow Up on Planned Breaking Changes in Commerce 2017
This is a follow up post to Planned Breaking Changes in Commerce 2017, which promised an update on the scope of the release. We now have the scope set, and are closing on dev complete for the included features. It is very close to what we planned a few months ago, so most of this is reiteration:
Improved Entry Sorting
It is now possible to correctly use the SortOrder of NodeEntryRelations to determine the order in which items are returned e.g. when calling IContentLoader.GetChildren to render a product listing. Marketers can set the order by dragging and dropping items in the Catalog UI. The Content's ParentLink property is independent of the sort order, and has separate interactions in the UI.
Reworked Catalog Import
Refactoring the catalog import code allowed us to squeeze out better performance, both in terms of import speed and memory consumption.
Improved API for Relations
The IRelationRepository and its data classes have been redesigned to use a Parent/Child terminology which we hope is easier to understand and use. In addition, the caching strategies for Relations (and Associations) has been improved and the data classes now implement IReadOnly (requring cloning before changing).
Order System API Improvements
- Return order form support has been added to the abstractions.
- The default order calculators have been corrected to not include order level discounts in the subtotal.
- The workflow calculations have been aligned with the order calculators.
- Some APIs related to payments have been changed to improve creation of payments from the abstractions, data available for processing and to better support redirecting payment providers.
- Shipping APIs have been extended to get rates by market.
Removing Legacy
- The WorkflowsVNext feature switch (i.e. use the new Promotion System) is now active by default.
- The legacy promotion system has been obsoleted.
- The legacy asset system has been removed.
- The dependency to nSoftware has been completely removed due to changes in how it is licensed. We will provide source code to help you build the equivalent functionality using your own licensed nSoftware library.
- The ApplicationID concept has been removed, affecting a number of APIs as well as tables, indexes etc.
Other
- A number APIs that have been marked as obsolete for a long time have been removed.
- The .NET Framework requirement has been lifted from 4.5 to 4.52.
What's next?
We have already started our QA process for several of the dev complete features. We will get the rest to dev complete together with compatible versions of Service API and Find for Commerce and get it all to QA. It is unlikely to be ready within Q2 as we previously estimated, but we hope it will be released soon thereafter. When it is eventually released we will of course also publish more detailed documentation on the new features and breaking changes.
Will it be 10.x version or 11?
Since there are breaking changes it will be 11.0.
Hi Magnus,
I suggest that you add the text "Commerce 11" into articles like this. For example, you could say, "Commerce 2017 aka Commerce 11" instead of only using branding like Commerce 2017. I've just spent 20 minutes trying to find this and February's article about breaking changes in Commerce 11 (I knew they existed because I read them at the time) but failing to find them using Search on Episerver World and on Google. I wonder how many of our colleagues, customers, and partners think that we've been quiet talking about the next version of Commerce because they don't see search results for Commerce 11?
I hope this suggestion helps.
--Mark
Thanks for the suggestion, Mark. I created a new Best Bet in the Epi World Find search. Now, if someone seaches on Commerce 11, this blog post is the top search result.
@Mark, first, I'm sorry for the late response. The reason I didn't want to specify the version was that we don't know the version number until it is ready for release. Something else could have come in between and we would have had to release some other breaking change as 11.0, pushing this to 12.0. This was certainly true when I wrote the original article in the beginning of this year. When this article was written it was fairly certain that it would be 11.0, but since it was a follow-up I kept the title... But you're right, I could have put the version number in the text (after all, I put it in a comment the same day).
As you have probably seen there's recently been an article about breaking changes in CMS, equally void of version numbers for the same reason. And we've done it this way before as well. When a major release is ready however, there will be a real article in the documentation (not "just" a blog post from the dev teams) describing the breaking changes. The one for Commerce 11 was published with the release in early August, which I realize is after you posted your comment.