A new version number — here's what changed and why

Products Password Secure News
1

Starting with our next release — 26.3.100 — Netwrix Password Secure moves to a new versioning format. If you’ve been keeping an eye on changelogs or planning updates, this post is for you.

:old_man: The old way: 9.2.3

SemVer served us well for a long time. But as our release cadence grew more frequent and
predictable, the classic Major.Minor.Patch format started creating more confusion than clarity… especially when a “Major” bump was triggered by technical internals rather than a meaningful change for you as an admin.

:sparkles: The new way: 26.3.100

The format is YY.M.VVV — year, month, and a release indicator.

That last part is where the real information lives:

Digit Meaning
Hundreds Major releases this month
Tens Minor releases this month
Units Patch releases this month

So 26.4.1 is the first patch of April 2026. 26.4.10 is the first minor update. 26.4.100 is
a major release. And they stack: 26.4.111 means one of each has shipped that month.

A note on build numbers: Inside the product, you may notice a longer number with an additional build identifier appended. That’s there for technical support and diagnostics. In all our communications — release notes, announcements, documentation — we’ll always use the short format above.

:rocket: Why this is better for you

  • Instant context. Just reading the version tells you when it shipped and how significant it is — no changelog lookup needed to assess urgency.
  • Predictable cadence. The year/month prefix makes it easy to see how current your
    installation is and to plan update windows accordingly.
  • No more version inflation anxiety. We’re not sitting at v10 just because of a database schema change. Major, minor, and patch mean what they say.
  • Cleaner upgrade conversations. When you’re talking to your team, your auditors, or us - “we’re on the March major release” is immediately meaningful.

:locked: What stays the same

Our commitment to backward-compatible upgrades, migration guides for breaking changes, and clear release notes — none of that has changed. Only the label on the box.

We’ll have full documentation on the versioning scheme in our knowledge base. Questions? Drop them in the comments. :backhand_index_pointing_down:

2 Likes
Password Secure Version 26.3.100 released
2

Hello,

Thanks for the heads-up. I personally believe SemVer is very clear in it’s system, while the new proposal isn’t. Starting a new release with .100 is absolutely not industry-standard.

Do you plan on ever releasing two major releases in one month? If not, what is the purpose of .100?

Kind Regards,

Lukas

1 Like
3

Very valid point, Lukas! Agreed to 100%.

Regards,
Markus Ruppel

4

Hey Lukas - thanks for the question and the honest feedback!

Short answer: yes, we want the flexibility to ship more than one release with breaking changes in a month… that’s exactly what the ‘.100’ enables.

SemVer has worked well for us, but we’ve seen consistent challenges around long-lived major versions, the overhead of major upgrades, and differing interpretations of what “major” really means.

With the new format, we’re aiming for a better balance across everyone involved - product, partners, admins, and users - while fully aware there’s no perfect solution.

Cheers,
-sascha

1 Like
5

The user wants me to translate German text to English.There are some initial bugs I have noticed: In forms (or individual form fields) that have a required field with a minimum length requirement, after updating to v26.3.100, the specified minimum length is no longer accepted. The message that the minimum length has not been reached always appears, even though it has been. The forms now need to be modified since no new passwords can be entered. The minimum and maximum length of the required field must be set to 0 for the entry of new passwords to work. In return, however, “already entered passwords” can no longer be changed and saved, as the message appears that the forms have been modified. - I request a prompt solution, as equipping all passwords with new forms represents an enormous amount of effort. I have also noticed that in the WebClient, not all form fields are visible and cannot be edited, whereas they can be in the FullClient.