Blog HomeBlog Archives:

New version management
for Fluid Topics

Starting with the release of v3.2, we are streamlining our version management and release process for Fluid Topics. Please find highlights of this new process below.

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.

search and find with fluid topics

Fluid Topics 2.6 boosts the search experience

We’re very excited to share today’s release with you. The new version of Fluid Topics delivers major improvements to the search experience. We’ve boosted the efficiency of information access by providing more knowledge objects in the unified search, the ability to preview content from within the search page, intelligent spell checker, and other features to improve the user experience

Version 2.6 also brings a very unique capability called Book Dynamic Filtering.

Documentation for Multiple Software Versions

Consider this case: a software vendor has its product available for on-premises installation in RedHat or Debian Linux distributions. Moreover, the product can be deployed on a single server or on multiple servers for horizontal scaling and high-availability. It can also use different database back-ends, such as relational or noSQL storage. With eight combinations available, the resulting documentation will include two options:

  1. Eight different manuals, published separately. This is costly to generate, especially with more options such as versions, it could include 30 or 40 documents. In addition, you have to ensure that users can easily find the right version.
  2. A single large manual that includes all information. Such a cumbersome manual will include a large number of subsections —“ for Debian”, “ for Redhat”, “ single server”, “ multiple server”— and multiple links. This sort of large catch-all manual is a potential source of errors, user mistakes and high support costs.

When searching for information, users may be offered facets for filtering and targeting the platform matching their situation.


When they rapidly spot the proper content, they click to open the manual and access the entire installation procedure.

But when users see that the book contains indications for all platforms and architectures, they can become frustrated knowing they have to struggle to find the proper content.


How Fluid Topics Book Dynamic Filtering Improves the User Experience

Book Dynamic Filtering solves this issue in the most elegant and efficient way. For example, facets that the user selects during the search phase are transmitted to the Fluid Topics embedded reader, which automatically filters the book accordingly.


The manual’s table of contents and its content looks as if it was generated specifically to match the user’s needs, with a property box displaying the active parameters.

book-properties toc-filtered

All of these functions are performed dynamically in real time by Fluid Topics. You don’t have to worry about generating multiple books or fear that your users won’t find the exact version they need. That’s the magic of Fluid Topics: true dynamic publishing delivered.

For more information about the other features of version 2.6, see the release note. Try out the latest update and let us know what you think.