Coming This March: A Simpler, More Predictable FME Release Versioning Model

Is there a target day within each release month?

Now when changing the versioning, is it correct to treat the version 2026.1 as equal to the “2025.3” (old versioning system)?

I’m thinking in the context of updating FME Flow from 2024 version directly to 2026, since the coming 2026 versions essensially are 2025 versions when using the old version system.

2026.1 is the first release of 2026

Instead of starting at xxxx.0, it starts at xxxx.1

If i understand correctly, in the previous version naming convention .x releases where ‘significant’ updates to the underlying year. That’s why you’d see 2025.3 released in 2026.

Now Safe are doing a quarterly release regardless of any ‘significant’ improvements. This provides a more structured and reliable cadence 

​@hkingsbury Thanks for your question! Our target timing for each quarterly release is generally the middle to later part of the release month.

My Question - so no more in between bug fixes - like current 2025.2.2 etc.

I would like to see - from a release, incremental updates. And also in place upgrade of FME Flow. And the current pain - Database. Upgrade option needed for Database.

Also currently the Database install are only available after you install FME Flow - like to see a download option.

Another that would be great is more administrator in the GUI - like amending config files. Stop and Start of services in one interface.

FME Flow and Form - IMO are amazing products, but I think we need more/better administrator tools/interfaces.

Rudy

Following each major release, we provide monthly updates that primarily include minor feature enhancements and bug fixes, which typically fall in the later part of the release month.  These updates follow a consistent monthly cadence outlined below:

• 2026.2.0 (Major)
  • 2026.2.1 (Update)
  • 2026.2.2 (Update)
• 2026.3.0 (Major)
  • 2026.3.1 (Update)
  • 2026.3.2 (Update)
• 2026.4.0 (Major)
  • 2026.4.1 (Update)
  • 2026.4.2 (Update)

Appreciate the feedback on the better admin/upgrade workflows ​@rudy_v. This more structured release cadence—and an increased internal discipline around what goes into each release—sets us up to be able to provide incremental updates in the future. It will not be in an immediate release, but it is on our radar.

So instead of updating to .1 we’ll update to .2. No big deal.

I posted a question to this announcement 

The reason the ".0" release is often avoided is that many organizations consider it the first production release of a new version branch, where undiscovered issues are more likely to surface. As a result, it is common practice to wait for one or more maintenance releases (e.g., x.y.2 or x.y.3) before upgrading production environments.

That said, every release introduces changes, and with those changes comes the possibility of new defects. In practice, there is rarely a "perfect" version to wait for. The decision to upgrade is therefore less about finding a bug-free release and more about balancing stability, risk, new functionality, and support requirements. So I don’t see any value in this except to trigger people to jump to a newer version sooner so the support job will be easier. Next time maybe they will start counting at 2 ;-)

26.1 with its switch to REST v4 has unfortunately had some regressions (in backups with timestamps and keeping the volume of documentation current i.e. databricks)

The old adage of waiting to subsequent releases in my opinion is worth it, simply to avoid having to make too many workarounds. I look forward to the benefits of this good initiative when potential patches (simpler in place upgrades) become available.