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:
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:
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!