Breaking changes in Commerce 15

When you upgrade to Commerce Connect 15, breaking changes means there are changes that could potentially disrupt or alter the functionality of your existing code, integrations, or customizations. Handling breaking changes effectively ensures a smooth transition and continued operation of your commerce implementation.

Here are the steps you should follow:

1. Review release notes – Carefully read the breaking changes in this document and the detailed articles linked below.
2. Assess impact – Identify which parts of your current implementation are affected by the breaking changes. This involves reviewing custom code, third-party integrations, and extensions that might rely on deprecated or altered features.
3. Plan for changes – Develop a plan to refactor or update the affected areas of your codebase. This might include rewriting custom code, updating APIs, or replacing deprecated features with their new equivalents.
4. Test in a staging environment – Set up a staging environment to test the upgrade process before applying it to the production environment. This lets you identify and fix issues in a controlled setting without affecting live operations.
5. Refactor code and update integrations – Make necessary changes to your code and integrations based on the assessment and testing. Ensure that dependent systems and workflows continue to function correctly.
6. Update documentation – Revise any internal documentation that references the old system behavior. This helps ensure that your team is aware of the new processes and any changes to functionality.
7. Perform regression testing – Conduct thorough regression testing to ensure that the changes have not introduced new bugs or issues in existing functionalities.
8. Monitor post-upgrade – After upgrading to the new Commerce version, closely monitor the system for any unexpected behavior or issues and be prepared to address them promptly.

By following these steps, you can effectively manage breaking changes, ensuring a successful upgrade with minimal disruption to your commerce operations.

Manage Commerce 15 breaking changes

Commerce 15 breaking changes to method signatures or to the behavior of methods, compared to the documented API in Commerce 14, are described across the following articles. Each article groups related changes by area of concern.

📘

Note

Binary breaking changes do not necessarily require code changes but rather just a recompilation of the project.

A breaking change may cause a component to fail. When a breaking change is made to a signature of a method, class, or interface, the former signature is often kept intact but set as obsolete and may cause a warning message in Visual Studio. In each major version, obsolete methods are removed permanently to keep the API clean and usable. For Commerce 15, many methods that were made obsolete in prior versions are deleted.

Classes that expose constructors that take dependencies are normally deleted without an obsolete warning in major releases because the compiler provides information about what you need to change. Keeping those classes makes dependency injection complex because, over time, there would be multiple constructors to choose from that might overlap.

Breaking changes by topic