|Number of votes:||7|
Many software companies release new versions of their software once a year, and maybe some smaller bug fix releases in between. Each time they release, they hit the big drum and make a lot of advertising for the new release. Customers have gotten used to this and wait eagerly for the next big release and hope for a bunch of new features. They might even wait with buying the software because they want the latest-latest.
At Episerver, we are taking another approach. In technical mumbo jumbo, it is called continuous releases (but never mind that, the term itself isn’t important) and that means we are releasing new features and bug fixes as soon as they are done. And tested, of course! This also means that we release almost every week of the year (okay, we may slack a bit around Christmas and New Year but generally, we release e v e r y w e e k!).
The main idea is that by releasing smaller upgrades every week, there is less risk of introducing major bugs, and the system is always thoroughly tested. Less work for us, less work for you.
Working this way is a great advantage for us. As the cycle is short between starting with a feature, testing, releasing and getting feedback, we have a good overview of each step in the process, and we can quickly fix issues not working so well. Creating the big bang release every year also has a huge cost, both in effort for the company and in dollars and cents.
It is also a great advantage for you, as users of the Episerver platform. Episerver developers can upgrade whenever they want to but generally, the more often they upgrade, the less hassle it is. And Episerver editors don’t have to wait another year for the next great feature in the user interface.
Another term we use is semantic versioning. The term itself is not important, but it is important to understand the concept, and how we think of our releases and how they are named.
When we speak of releases, we tend to use one, two, or three digits, as in Episerver 10, Episerver 10.2, or Episerver 10.4.3.
First of all, we call the single-digit releases (such as 8, 9, and 10) for “a major version”. Major versions are releases that have some breaking changes. And by breaking changes, we mean that a developer may have to change something in their code before they can upgrade. But if you are an editor, there may not be a single change between the previous version and the new major version.
A release with two digits (also called "a minor version"), such as Episerver 10.2, is a release that has some new features. The new features can be either inside the software (what we call CMS Core) or in the user interface (CMS UI). (I’m mentioning just Episerver CMS here, but all parts of the Episerver platform are released and versioned the same way.)
A three-digit release, such as Episerver 10.4.3, is a release which contains only bug fixes. It does not contain any new functionality.
So between versions 10.1 and 10.4.3, there are new features and bug fixes, but upgrading should be very smooth since there are no breaking changes.
Our releases are also cumulative, which means that release 10.8 contains all the features and bug fixes that were released in 10.7.9 and 10.5 and all other previous releases.
So, if you are a developer, this means you are most interested in the major releases, as these may give you more work than simply just pressing the Upgrade button. But note the word *may*, your specific site may not be affected by the breaking changes at all.
As an editor, you may be more interested in the minor versions, because that’s where most of the goodies are released. If we take the Episerver 10 release as an example again, the 10 release didn’t include anything fun for the editor at all. But the 10.1 release did, as did the 10.7 release. In release 10.1, you got the first sneak peek of the content approvals feature, and in release 10.7, content approvals were implemented for assets such as blocks and media.
The Episerver platform is built up by Episerver CMS, Episerver Commerce, and Episerver Find. In addition to that, there are a number of add-ons, which contain functionality not included by default in a standard installation but can be added to enhance the product. Some of them are built by Episerver and some by third-parties. Some of them can be used for free, while others require an additional licence.
When we release a new major version of Episerver CMS, we know people are eager to get it and start working with it. So we prioritize releasing it as soon as it is ready, which means that some add-ons have not been tested against the new CMS version at the release. After a major release of Episerver CMS, we update the add-ons to support the latest CMS version, but this is a process which takes some time. If you are using add-ons, you can check the Add-ons compatibility page to see which CMS versions support the add-ons you are using.
We try to keep you informed of what we have in the pipeline, and the different teams generally blog about major releases before they are released as a heads-up. New features are also released as Beta features while still under development, to give you a chance to try them out and give us feedback. Beta features are tested but should not be used on production sites as they may be changed without prior notification.
When we release each week, we publish what we call “a weekly update” on Episerver World. The weekly update includes information on what is being released and it also links to a release feed. The weekly update also includes links to relevant updated documentation.
Example of weekly update:
The release feed displays all new features and public bug fixes and you can easily use this to sort out information for a specific release:
With the short test and release cycles we have, it just isn’t possible to say when the next major or minor release will be released. We release major versions when we have enough breaking changes to warrant a new major version. Minor versions are released as soon as new features are thoroughly tested. We never release anything unless all tests are green.
The best recommendation we can give you is that you try to be as up-to-date as you can be. The more up-to-date you are, the easier it is to upgrade each time.
The weekly update is often full of technical details and aimed at the developers who are responsible for doing the upgrade at customer websites. Four times a year, we summarize all new features that were released since the last time in what we call feature lists. They are found on Episerver World (our community site) and are intended for editors, or other people interested in new functionality.
You find shortcuts to the weekly updates, release feed and feature lists under Releases and features on the Episerver World start page:
From Documentation in the top menu of World, you can find developer documentation but also a link to the Episerver User Guide, which is aimed towards editors and descibes how to work with the Episerver platform.
The user guide isn’t released every week but we try to release it every month, if necessary. There is a section called What’s new which shows the last weekly update that it covers. Many new features are also demoed in short videos.
If you prefer to rather print the user guide and read on paper, you find PDFs on the User guides for print page.
As you probably already know, Episerver World is full of information for you. Regarding releases, the most useful information is:
Note that if you want to try out features still in Beta, you need to enable these features by defining a EPiBetaUsers role in your system. See Fredrik Tjärnberg’s blog post.
System manager? IT boss?
If you are more interested in the future than the past, we plan on keeping our roadmap available on World. This is still work-in-progress, but keep your eyes open.
Thanks for the clarifications!
This is a great article which helps clarify a few points - thanks!
Thanks so much Asa. This article is very clear and specific.
You mention that you use semantic verisoning, and yet you introduce breaking changes in minor and patch releases.
Update 163 (patch release of EPiServer.CMS.Core 10.9.1) removes support for SQL Server 2008 R2, a major breaking change in infrastructure.
Update 159 (minor release of EPiServer.Forms 4.5.0) changes the markup used in form components, breaking the public API that the markup constitutes.
What is your rationale for introducing these changes now, instead of waiting for the next major release?
EPiServer.CMS.Core follows semantic versioning which means we never break the public API without doing a major version. Same goes for all our packages, if you find something like what you mention in Forms open a support case so that the team is notified and can address it - mistakes can always happen ofcourse and should be corrected as soon as possible. Changing dependencies is not considered a breaking change according to semantic versioning.
Another aspect of this tight release schedule is that it's a badge of excellence for the Episerver technical team. You can't do this on a product if you haven't already invested in unit tests, CI and cleaned up the worst of the technical debts.
It's a good sign that you have a product that can keep pace in rapid torrents of our digital world.