What to Expect from Vanilla LTS ReleasesSome Enterprise customers have more complex development workflows, including local Vanilla development, custom code, or more involved internal QA processes. For those customers, Vanilla offers a Long-Term Support (LTS) release path.
Code Deploy customers are required to follow the LTS release path. The vanilla-local repository used for local development is updated only with LTS releases, helping keep local development aligned with the supported LTS version. For more information about Code Deploy requirements, see Self Code Deploy (VF Code Deploy).
You can follow this knowledge base to receive updates when new Vanilla LTS releases are announced.
What Is an LTS Release?
LTS stands for Long-Term Support.
For Vanilla, an LTS release provides a slower, more predictable release path for select Enterprise customers who need additional time to test and validate changes before they reach production.
Instead of receiving every standard Vanilla release as it becomes available, LTS customers receive updates three to four times per calendar year. Exact timing may vary depending on the size, complexity, or timing of major product releases.
Supported LTS versions receive applicable bug fixes and security patches. New features are not added to an existing LTS version; they become available when customers move to a later LTS release.
Review the Bug Tracker for information about published bug fixes.
Why Use an LTS Release Path?
LTS releases provide more control over testing and planning. The LTS release path is required for Code Deploy customers and may also be appropriate for other eligible Enterprise customers with complex development or QA requirements.
The LTS path can be useful if your team:
- Maintains a local Vanilla development environment
- Builds or maintains customizations
- Has a formal QA process before production updates
- Needs fewer release events to manage
- Coordinates Vanilla updates with internal development or deployment cycles
Benefits of LTS Releases
LTS releases can provide:
- More predictable planning
- Fewer release events
- More time to validate changes in development and staging
- A more stable development baseline
- A clearer path for testing customizations before production
How LTS Releases Roll Out
Vanilla deploys an LTS release in stages:
- Week 0: Staging, LTS development, LTS staging, and the
vanilla-local repository - Week 1: Public and Corporate production sites
- Week 2: Enterprise production sites on the standard release path
- Week 3: Enterprise LTS UAT sites, where a separate UAT environment has been purchased and configured
- Week 4: Enterprise LTS production sites
Release timing is subject to final readiness and may change.
Week 3 does not apply to every LTS customer. It applies only to customers with a separate Enterprise LTS UAT environment. An LTS customer's production deployment remains a distinct Week 4 step.
Enterprise LTS UAT Environments
UAT stands for User Acceptance Testing. An Enterprise LTS UAT site is a separate customer environment where an eligible Enterprise Plus customer can validate an LTS release before it reaches their production site.
A UAT site is not automatically included with Enterprise Plus or with an LTS release. Enterprise Plus customers interested in a UAT environment must work with Sales to discuss eligibility, cost, availability, and next steps.
Only customers with a purchased and configured UAT environment receive the Week 3 Enterprise LTS UAT deployment. Enterprise LTS production follows separately in Week 4.
Things to Keep in Mind
There are also a few trade-offs with LTS releases.
Customers on an existing LTS version continue to receive applicable bug fixes and security patches, but they do not receive new features introduced through the standard release cadence. New features become available when customers move to a later LTS release.
Moving to a later LTS release may introduce changes from several standard Vanilla releases at once, which can create a larger set of changes to review and test.
Custom code should still be reviewed and tested against each updated LTS version.
Standard Releases vs. LTS Releases
The standard Vanilla release cadence is best for customers who want access to improvements and new features as they are released.
The LTS release path is designed for eligible Enterprise customers who prioritize additional testing time, fewer release events, and more predictable planning around development and QA.
Code Deploy customers are required to follow the LTS release path. For other eligible Enterprise customers, the appropriate release path depends on the team's development process, QA needs, and release-planning requirements.