New version management for Fluid Topics

We are DevOps

We compile, test and deliver one new version of Fluid Topics every week, usually on Monday. Each released version is valid for production. However to avoid unnecessary disruption, we only upgrade our SaaS production environment every 2 to 4 versions, depending on needs, which include for example the roll out of a fix or of a new feature awaited by customers. On-premises customers can install any released version, not necessarily one of those we have deployed in our cloud environment.

We are also always ready for a hot-fix since at any time we can correct a critical bug or a security issue, compile and certify a new version, and put it in production in a few hours, even if it’s not Monday. And because we deploy frequently (every 2 to 4 weeks) we are fully confident in our processes and tools.

We are Agile

We develop using Agile principles. Our sprints last 3 weeks. Each modification or new feature, whether it can be developed within one sprint or over multiple sprints, is held in a distinct commit or in a separate code branch. This way, we have tight control over what can be included in any new version.

We apply Version Numbering

Fluid Topics releases each have a distinct version number of the form P.M.m where:

• P is the platform (currently P=3),
• M is the major version,
• m is the minor version.

For a given platform, minor and major versions are always backward compatible.

For each “new version of the week” we increase the minor number: 3.2.1, 3.2.2, 3.2.3, etc. As we update release notes synchronously, you can easily follow the news.

Starting in May 2017 with availability of v3.2, we will release a major version 3 times a year: in January, May and September. Hence version 3.3 should arrive in September. This release schedule is a significant change: there have been 42 minor versions of Fluid Topics v3.1 and nine months has elapsed before we released Fluid Topics v3.2 — from 3.1.0 in July 2016 to 3.1.42 in April 2017.

So why are we making this change? Why can’t we stick to continuous delivery? Why do we need minor and major versions anyway? Simple reason: Change Management.

We back Change Management

Some of the features we develop are invisible to your users: a performance improvement, a new admin interface, a technical enhancement, a new supported format, etc. These new capabilities are integrated into Fluid Topics and officially released as soon as they are ready. Hence some minor versions may in fact bring huge things. But usually your users won’t notice because it does not change the UX and the existing interface.

Conversely, some changes or added features may impact the UI and the habits of the users: a button moved, a label changed, a layout redesigned, etc. And you need time to warn them, maybe update some screenshots and documentation, or just prepare a newsletter to advertise the function.

Therefore, visible changes don’t get integrated on the fly in minor releases, even if they are ready. We wait until the next major version. And in this case, to give you time to organize the change management, we make the features available in preview environments at least 3 weeks in advance; for those of our SaaS customers having a test environment, we will also update it 3 weeks before the general availability of the major release.

Hence the timeline of a major release is organized like this:

In all cases, whether visible or not, we publish the list of enhancements, modifications and new features 3 weeks before General Availability; and we update the roadmap for the upcoming major version.

Regardless of the delivery schedule, we still are eager to get feedback on each version and feature and to have our customers help us make Fluid Topics the best Dynamic Delivery solution in the market.