For some time now, we have been contemplating changing the way we release Synergy products. This will not be a surprise to many of you; we’ve been “testing the waters” during conversations with many of you for well over a year now, and I presented information about the likely changes in my Product Update presentation at the DevPartner conference back in May. What has changed since then is that our plans have been formalized, the changes are definitely happening, and we are drawing close to what will be the first release under the new scheme. With that in mind, it’s probably a good time to tell you all about the changes that you can expect.

Before I talk about the actual changes, let me first explain what we are trying to achieve by making the changes.

Known Release Cadence

Previously, Synergy products have not had a pre-set release cadence; we released a new version of the product when we felt a significant new functionality or change in technology justified doing so. As a result, the time between releases could vary from as little as a few months for minor releases (e.g., 9.3 in December 2009 and 9.5 in November 2010) to several years between major releases (10.1 in December 2012 and 11.1 in September 2019).

While this probably works fine for most of our “end-user” customers, it can be challenging for ISV customers that release their products on pre-determined schedules. A known release cadence will make it easier for them to plan their releases, specifically when to adopt new Synergy versions, because they will know when to expect a new Synergy release in advance.

Known Support Window

Similar to the release cadence, the support period for the current Synergy version has previously also been undefined. Our commitment has been to support the current and previous major or minor releases (currently 10.3.3 and 11.1.1), and any earlier versions are technically unsupported. By the way, in this context, “supported” refers to the versions of the product for which we will issue patches if a customer finds a serious problem, not to the ability to call the Developer Support team for assistance. Our support engineers will always try to help supported customers, regardless of product version.

Improved Stability

As our development practices became more “agile” in recent years, so did the way we released software. We got to the point where every release we published (even “patch letter” releases) typically included new or updated functionality in addition to quality enhancements. While this is great for developers who want access to the “latest and greatest” features, the strategy sometimes wasn’t great from the point of view of product stability. It’s a fact of life in software development that new or altered code means an opportunity for new bugs, but it’s frustrating if that happens in the context of a patch letter release that is supposed to fix bugs, not introduce new ones.

We have already partially addressed this issue, as I discussed in my Improving Our Internal Development Process blog post last September, but the changes we are about to make will enhance product stability even further.

Introducing Long-Terms Support (LTS) Releases

We are switching to what is referred to as a Long-Term Support (LTS) release strategy. LTS releases provide customers with a pre-defined schedule of Synergy releases that they can plan against, as well as the opportunity to deploy applications in an inherently more stable environment.

Each LTS release will contain a pre-determined set of new and enhanced features that will not change post-release. Further, the features introduced in an LTS release will have been previously made available and thoroughly tested in earlier “feature releases” (more on this later).

LTS releases provide an inherently more stable environment because of the absence of newly introduced or altered code. Although an LTS release may have subsequent updates, those updates will only contain quality improvements or security enhancements, not new functionality.

We plan to make a new LTS release available every two years, the first being before the end of this year. Synergy has many close ties with Microsoft .NET, and we will be broadly aligning our release schedule with that of .NET, which also uses an LTS strategy with a two-year cadence.

LTS releases will be labeled with a version number, an odd revision number, and an incrementing build number. The first LTS release will be 12.1.n (n being the build number). After that will be the 12.3 LTS release in late 2023, the 12.5 LTS release in late 2025, and so on. There will be no patch letter releases under the new scheme.

Each LTS release will be supported for a minimum of four years, or one year after the next LTS release ships, whichever is longer. So if you adopt the 12.1 LTS release when it ships in late 2021, you know it will be supported until at least late 2025.

Feature Releases

Of course, some developers will take advantage of LTS releases for the improved stability they offer, but others will want to get their hands on the latest and greatest features that have just been developed, and that is where feature releases come in.

Feature releases are interim releases that provide early access to new features and enhancements that will eventually become part of the next LTS release. They may include partial (but usable) implementations of new features. They will also address any quality and security issues identified within the feature release branch.

Occurring on a more frequent cadence than LTS releases, multiple feature releases may occur each year. You can think of feature releases as being more similar to the way that we have released our software in recent years.

Feature releases will typically be made available for all supported platforms, but if the changes in any release do not apply to or are not usable on a particular platform, no release will be made for that platform.

We will fully test feature releases to the best of our ability, but developers should bear in mind that quality may be lower in areas where new code has been added or significant changes have been made. Quality will solidify as developers exercise the new or updated features and as our automated test suites are extended.

The support period for feature releases will be much shorter than for LTS releases, ending three months after the next feature or LTS release.

Feature releases will be labeled with a version number, an even major revision number, and an incrementing build number. This may seem a little strange, but remember that feature releases build-up to the next LTS release. The feature releases to support the upcoming 12.1 LTS release will be labeled as 12.0.n. We’re currently in the process of putting together the first such feature release, which you may see towards the end of this month or in September.

This first release may not seem too unusual because we will be going from 11.1 to 12.0 and then to 12.1 later in the year. But shortly after the 12.1 LTS release, the first 12.2 feature release will occur (leading up to the 12.3 LTS release in 2023). For the next two years, you will see releases in both the 12.1 and 12.2 release branches, not necessarily at the same time! For example, there may be a 12.2 feature release in March, followed by a 12.1 LTS release in April!

The build number will start at 1000 the first time we build the product in a new feature release series and will increment by 1 every time we build the product, regardless of whether that build is internal, or released to customers. And the sequence of build numbers used with a feature release will carry forward to the associated LTS release. For example, if the final 12.2 feature release is 12.2.1263, then the first 12.3 LTS release might be something like 12.3.1279.

Remember that you can take advantage of runtime version targeting, which allows you to ship your products to customers (external or internal) using an earlier and stable version of the Synergy runtime (the LTS runtime) while developers use the latest feature release to build the product, enabling them to take full advantage of all of the ever-improving productivity enhancements in our Visual Studio IDE tools.

If you have any questions about anything that I have presented here, please do not hesitate to contact me via email at steve.ives@synergex.com. And if you are interested in the changes that will be included in the upcoming 12.0 feature release, watch this space—I will post about that soon.