We are changing our release model so the version numbers give a better indication of what type of changes the release contains. We are also putting more effort into helping with upgrading, so everybody can stay on the latest version instead of an old one.
We have been listening to your concerns about how the frequently changing Vaadin version numbers make it difficult to keep up. We realize that most of you are using the LTS (long-term support) versions to avoid any uncertainty about whether the next quarterly release will be trivial or disruptive for your application. Moreover, when the next LTS release comes out, you face the challenge of a potentially substantial upgrade project.
At the same time, we've also been observing how our own ways of developing Vaadin are affected by the way we're releasing. With most of you using an LTS version, we have additional work, since it increases the demand for backporting new features and releasing new minor versions, such as Vaadin 14.8. Additionally, planning our roadmap around an upcoming LTS release leads us towards focusing on breaking changes that we might need to get done "just in case, before it's too late", rather than focusing on building new features.
This simpler release model makes it easier for you to stay on the latest version while enabling us to focus more of our feature and improvement work towards a single version.
Have any questions about the new release model? Join us on the Vaadin Discord on the 27th of January where we'll open a thread on the #announcements channel to answer all your questions.
Minor releases add new functionality while retaining the old
Starting from Vaadin 23.0 in March 2022, we will focus on a single version instead of splitting our efforts between separate LTS and non-LTS tracks that have mostly the same features, but packaged in different ways. We will continue with quarterly releases that include all the features and fixes which are ready by then. Most of the quarterly releases will only increment the minor version number, e.g. from 23.0 to 23.1. Each version is maintained until three months after the following minor release. As an example, Vaadin 23.0 is due to be released in March 2022, and then 23.1 follows in June, after which 23.0 would still be maintained until September.
Regular bug fixes will be targeted only for the most recent version. The main exception is with critical fixes to security issues or browser incompatibilities, which we will fix as quickly as possible for all maintained versions. Fixes done through the Warranty service will also be targeted to whichever maintained version you're using.
We will ensure it's easy to upgrade to the next minor release, but there may still be some small breaking changes, such as changing default values for configuration options or making API adjustments that are necessary in order to address security issues. Old functionality will be retained in minor releases, but it might be deprecated, moved to an optional dependency or require an explicit configuration flag to function after updating. In this way, we make it easy for new users to benefit from what we've learned, without requiring us to maintain multiple versions.
The overall software development trend has consistently been towards continuous integration, shorter cycles and more agility. We want to encourage you to incrementally take new functionality into use to replace parts that are being phased out, rather than collecting a long backlog of technical debt that eventually needs to be addressed. It's basically the same volume of changes that are needed regardless, but an incremental approach removes the need for massive projects with lots of interdependencies and the resulting risk of complications.
Major releases bring in the occasional disruptive changes
Occasionally, it will be relevant to make more disruptive changes, such as increasing the required Java version or migrating from javax.servlet to jakarta.servlet. We will also accumulate old deprecated functionality that will gradually slow us down until it's eventually removed. We will increment the major version (e.g. from 23.4 to 24.0) whenever we make such disruptive changes.
If you have incrementally kept your application up to date by moving away from deprecations introduced in minor releases, then you will already have done most of the work that's needed for upgrading to the next major release. The overall ecosystem with the add-ons and libraries that you're using and the way you're deploying your applications might still prevent you from upgrading immediately, even if the application's own code is ready.
To ensure enough time for add-ons, libraries and servers that must be upgraded before a new major release can be adopted, we will keep maintaining the last major series for an additional 12 months for free. Just like with the overlap time after minor releases, the maintenance for the previous major series will also be primarily focused on making sure your existing application is safe to keep in production while you're working towards upgrading.
In some cases, 12 months isn't enough time to upgrade. Maybe you're in prolonged crunch mode to deliver significant new functionality, maybe you are in a regulated business domain with rigorous validation requirements for major upgrades, or maybe you're no longer actively working on the application because it's already perfect. We don't want to leave you hanging in such situations, but we're also painfully aware of how maintenance of older versions leaves less time for us to make future versions of Vaadin even better.
Beyond the initial 12 months of free maintenance after a new major release, additional fixes for the previous major series will become commercial. Users with a Prime or Enterprise subscription will get maintenance releases, without additional cost, for five years after the initial release of a major series and, beyond that, up to a total of 15 years with separate Extended Maintenance agreements. At the same time, we want to make it very clear that we expect that three months of overlap after minor releases and 12 months after major releases will be more than enough for a large majority of Vaadin users.
Feature evolution between minor releases with the help of feature flags
One of the ideas behind the way we've been releasing versions 10 - 22 of Vaadin has been that we can introduce new functionality in a major release to get feedback from early adopters. This early feedback gives us the opportunity to further tweak the design before the new functionality is made "permanent" in an LTS version. At the same time, this potential uncertainty has made it difficult for many of you to use versions without the LTS label, since you couldn't know whether rework would be needed to upgrade your application to the next major release.
Going forward, we plan to introduce new functionality for early adopters to try out in minor releases. To avoid the risk that someone starts using functionality where the requirements or design might still change based on early feedback, each such feature will have a feature flag that must be explicitly enabled before the functionality can be used. APIs associated with such functionality will also be marked as deprecated (though not for removal) to reduce the risk of them getting in the way for general use.
In this way, we will introduce smaller improvements as well as new major functionality in parallel with existing features in a way that doesn't require releasing a new major version immediately. Whenever possible, we will also make it possible to incrementally start using new functionality in some part of an existing application without first having to rework older parts of the application. There may, of course, eventually be a new major release where the old elements are removed, but you should by then have had a chance to start adopting the replacement and you will also have at least 12 months of overlap time to complete that work.
Summary
We want as many users as possible to be able to use the latest version. To achieve this, we will mostly do minor releases that introduce new functionality without removing any functionality. When new functionality overlaps with the old, we will include both the new and the old implementation of a feature or API, so that new users get access to the improvements without requiring old code to be rewritten immediately. In this way, you can gradually upgrade your application to follow our best practices and be prepared for the day when more disruptive changes need to be made in order to ensure that Vaadin stays relevant.
This new release model makes it easier for you to keep using the latest and greatest version of Vaadin, while also helping us increase the pace of improving Vaadin.
Have any questions about the new release model? Join us on the Vaadin Discord on the 27th of January where we'll open a thread on the #announcements channel to answer all your questions.