Configured Commerce - Introduction to Long-Term Support (LTS) Releases

First off, for those who have not had a chance to meet me yet, my name is John McCarroll, and I am the Technical Product Manager for the Optimizely Commerce team.  I work with our Engineering and Product Management teams to provide guidance on technical topics as they pertain to the future of our commerce products.  I’m also the direct Product Manager for Mission Control, which supports deployments, infrastructure, and observability for Configured Commerce.

With our October release, for the first time we will be offering our Long-Term Support release on Configured Commerce.  Find below a small FAQ about this feature.

Optimizely is still on the path forward to true versionless SaaS with externally-hosted extensions for Configured Commerce, but we recognize the need for some customers looking to have more predictability with upgrades in the meantime as we tackle this large project.

Please also find our user-facing documentation on LTS and STS releases here and our developer documentation here. 

What is Long-Term Support (LTS)?

This is an exciting evolution of our current release structure, where customers who are looking to take a longer-supported branch that will accept hotfixes for its entire four-month release cycle, rather than the one-month cycle for our Short-Term Support monthly releases.

Long-Term Support branches will also inherit the features of the previous STS release.  This means when we publish our October release, currently slated for October 19, we will release 5.1.2310.nnnn+STS (our monthly, Short-Term Support release), and 5.1.2309.nnnn+LTS (our thrice-yearly Long-Term Support Release).

In January, we will formalize the regular cadence of January/May/September LTS releases.  This gives an LTS branch a lifespan of four months. The LTS cut in October will have a three-month lifespan in which to receive hotfixes before we move to the standard four-month cadence.

How do I implement a Long-Term Support release?

Like any release today – the Versioninfo.yaml file that lives in your Github Repository that contains your extensions code allows you to designate a version to be deployed.  To deploy your desired version, simply add the version number of the release you’d like to this configuration file and deploy that code.

Can I swap between LTS and STS releases, if there’s a new feature I want in the STS release?

Yes, with the same caveat that you have today – your version number must increase when you implement a new version.  Optimizely Configured Commerce does not support downgrades of code versions, and this new release structure is no different.  You can swap from 5.1.2309.nnnn+LTS to 5.1.2310.nnnn+STS, but you cannot take the reverse path – version numbers must go up. 

IMPORTANT NOTE: This means you will need to wait until the next LTS release to return to the Long-Term Support versions.

Is LTS right for my Configured Commerce implementation?

Customers who are interested in staying up to date with the latest features will not want to shift to LTS releases. The iterative release cycle for Configured Commerce means that customers who want to be on the leading edge of their development should continue to take STS releases that contain desired features as soon as they are released.

However, customers with high-complexity customizations or customers looking for additional predictability into their upgrade scheduling may want to select the LTS releases.  LTS provides additional predictability to the release cycle by spacing it out, but that comes at the cost of new feature functionality only being released three times a year.

We recommend having this conversation with your implementation partner, as well.  Your partner will shed additional insight on how these versions will impact your current release cadence.