The Version Number Every RAXXO Tool Follows and Why

Every RAXXO tool adheres to strict semantic versioning, which consists of a major.minor.patch structure. The rule is uncompromising; a patch release only addresses bugs, a minor release adds new capabilities without altering existing functionality, and a major release is permitted to introduce breaking changes, provided they are clearly communicated.

I once violated this rule, releasing a patch without warning, which only served to create an unnecessary support thread. The version number and changelog serve as a mutual commitment to maintain transparency and trust with users, and skipping either one undermines that trust.

While some may assume version numbers are irrelevant for individual developers, I quickly learned otherwise after expanding my RAXXO tool portfolio to five live products and experiencing a surge in support inquiries. A customer who purchased my tool eight months prior and only uses it sporadically would be none the wiser about the changes made in that time. Semantic versioning allows me to provide consistent answers to these inquiries without needing to correspond with each user individually.

Adhering to this discipline requires restraint when tempted to bundle minor improvements into patch releases. I now apply a simple test: could a user with automated workflows update to the new version and have their processes remain unaffected? If there's even a chance of unexpected behavior, the change does not qualify as a patch. This rule is particularly crucial for tools that include APIs or scriptable interfaces, as external code may depend on the tool's stability.

For minor releases, I allow additions such as new settings, export options, or views, as long as they do not impact behavior for users who remain unaware of the new features. Major releases, however, are reserved for changes that fundamentally alter the tool's behavior, even if they initially appear minor. Dependency updates can also be patch-level changes if they do not alter the tool's observable behavior.

Yet, I have been guilty of allowing library upgrades to sneak into releases that should have remained pure bug fixes.

Ultimately, the value of this discipline lies not in the rule itself, but in the commitment to never compromise the trust of my users. Semantic versioning provides a consistent framework for communicating the shape of risks when updating my tools, without dictating the urgency or severity of the changes. I also recognize that the version number is only as reliable as the effort I invest in testing the release. Even a patch with an undiscovered bug remains a bug, and I refuse to let the label obscure that fact.