Understanding the Commerce Server Engineering Lifecycle

  • Article

Another topic we wanted to shed some light upon is how we are engineering Commerce Server, now that we are running entirely upon our own. Our approach is as follows – and by design quite different from how the product was curated at Microsoft. This also will set the stage for also how we will be supporting the product, which will be the topic of a few other posts in the near future. In short:

  • We will target a Major release of Commerce Server each year, which will deliver significant new functional and technological enhancements
  • As we can incrementally deliver new features on top of an existing Major release without causing excessive breaking changes, we’ll ship Minor releases; we may also occasionally ship Minor releases to add additional support for new Base Platforms (e.g. – versions of Windows, SQL, .NET, etc.)
  • Customer-reported problems will be fixed in the form of Patches, which will be delivered on top of Major and Minor releases

For every Major/Minor release starting with our next release, we will have the latest set of Patches and a Recommended set of patches. We will require customers to be at the Recommended set of patches for a given Major/Minor release in order to obtain technical support.

At the same time, we are making major engineering investments to make the process of applying Patches seamless relative to how it works with Commerce Server 2009 R2, Commerce Server 2009, or preceding Microsoft products.

In addition, we are managing our public roadmap disclosures in accordance with our engineering lifecycle. When we took over the product, we made three commitments at the end of 2011 for the 2012 calendar year from a roadmap perspective:

  1. Ship a re-branded version of Commerce Server 2009
  2. Ship a re-branded version of Commerce Server 2009 R2
  3. Ship the next major release of Commerce Server, delivering major improvements in up-and-running and maintenance around building Commerce Server sites

We have delivered on the first two, and the third remains on track to be complete by end-of-year.

When we make the marketing debut of the next major release of Commerce Server (which will be coming much sooner than end-of-year), we’ll update our public roadmap accordingly. And then repeat the cycle for every Major release thereafter.

Why do it this way? It’s simple in our eyes – this cadence lets us provide concrete guidance on what’s next for upgrading, yet remain agile to best respond to customer, partner, industry, and prospective customer feedback and adjust our plans as needed.

Hope this helps!