Magnus Rahl
Aug 4, 2016
visibility 4272
star star star star star star
(4 votes)

Episerver updates are released weekly

Every now and then I see the claim that Episerver releases product updates every two weeks. This isn't quite correct, and the truth is even better: We release updates every week!

This is probably nothing new for anyone who updates frequently and sees the new versions pop up on the NuGet feed. But since the two week misconception pops up again and again I wanted to set it straight.

I don't know where this claim originally came from, the article outlining our continuous release process, posted years ago, mentions weekly updates. But with a little detail on how we work you will see where the two weeks are in the process, possibly giving rise to this misconception.

We have a continuously running planning process where we research and design features, triage bugs and reprioritize the development backlog. The dev teams pick features/bugs from the backlog and implement/fix them. Automated builds, tests and metrics continuously run on the code being committed. Our QA teams pick up and verfy the built packages give thumbs up/down for release.

Because of the high level of automation, the cadence of this dev-QA-release pipeline is only limited by the time it takes to develop something, perform any manual verification necessary, and smoke test the package as a whole for side-effects. However, for the sake of completeness and consistency (and frankly, sanity) we do not pass every package built from development to QA. Instead, we aggregate the features and fixes completed within a week and branch off a release candidate (prerelease) which QA go on to verify. With the release window coming up once a week, this on average gives QA one week to verify the package and for dev to fix any issues found by QA.

Here you have the two weeks - it is the "delay" from start of a development cycle to the first possible release window for that code after verification. But of course the dev team isn't idle while while QA are verifying a package. They are already working on the next set of features/fixes to be passed to QA the following week, which is why a new version of the same package can be released every week.

Finally, the delay for fixing a high priority bug can be even shorter as a fix can be developed and included late in the dev week, closing in on a one week round trip time.

Aug 04, 2016

Comments

Arild Henrichsen
Arild Henrichsen Aug 4, 2016 12:55 PM

Thanks for the reminder! I'm guilty of spreading that misconception - most notably here: https://www.epinova.no/en/blog/5-proprietary-wcm-myths-busted-by-episerver/

Don't quite know how I arrived at that - reading the update list from 2015 now, it's clear that UI and Core updates were released weekly even then.

I'll update my blog post, and will be sure to spread the good (correct!) word!

Magnus Rahl
Magnus Rahl Aug 5, 2016 02:28 PM

@Arild: I was certainly not out to point fingers in any direction. And it is not a big deal. I'm glad the information is correct in more places now, thanks!

@Kashif: I'm not familiar with the issue you link to but in general terms we always strive to reproduce the bugs we get reported in an automated test wherever possible, so that we can verify consistently that the bug is fixed and that it does not get reintroduced. We do this for performance issues as well. Still, for any of a number of reasons it might not be water tight.

I'll ping some people to get responses to your specific questions but I know some of the ones previously involved are still out of office for summer vacations (as am I), so you might not get a response immediately. Meanwhile I suggest you open a support case about the performance issue, making it possible for you to share copies of your database and code with our support engineers so we can reproduce your issues and figure out what the previous fixes are missing.

error Please login to comment.
Latest blogs
Composition Over Inheritance: Why Your Content Contract Is Not a Base Class

Inside the structural conformance pattern in SaaS CMS — from server-side inheritance to pipeline governance. A contract in Optimizely SaaS CMS is...

Vipin Banka | Sep 19, 2026

Optimizely Opti ID Integration: Why the API Key Was Missing from the DXP Management Portal

While working on an Optimizely CMS 12 Opti ID integration recently, we ran into an issue that initially appeared to be related to SSO authenticatio...

Madhu | Sep 18, 2026 |

Extending a Contract: What You Can Override

Contracts share fields across content types — but not every field setting can be overridden. Push the same contract onto several components, and CM...

Chirag Khanna | Sep 18, 2026 |

Building a Blazor Server UI Inside the Optimizely CMS 13 Admin Shell

What I learned shipping a Blazor Server UI inside Optimizely CMS 13 — Razor components in a NuGet package, the Blazor hub next to MapContent(),...

Stanisław Szołkowski | Sep 17, 2026 |