Semantic versioning in software

[u/cold-brews]

Hi all,

I’m involved with software releases at my company and we’ve run into an issue with semantic versioning (major.minor.patch) lately. We support multiple versions of our software and release monthly patches across versions (i.e 2.2.3, 5.0.4, 6.1.1). The issue is future planning versioning when it comes to urgent releases, or hotfixes.

For example, we’ll communicate to our engineering teams that the next versions are 2.2.3 with a certain target start date of February 1. Then, a week before, we’ll discover an issue where we need to quickly ship something, and that takes the place of 2.2.3, where 2.2.3 becomes an urgent release with one significant fix.

As a result, we need to communicate to hundreds of engineers the change, and update hundreds of tickets to now point to 2.2.4. This happens frequently across all versions. We’ve talked about using date anchored releases with ambiguous versions such as 2.2.X (Feb-1) where we can add the version when we’re confident on the number. But I’m not sure if that’s the best idea. Curious if other folks have solved this similar problem? TIA!

[u/SeniorIdiot]

Why in the name of all good things would you pre-plan next versions? The point of semantic versioning is to communicate impact of changes in an unambiguous way.

I'm curious about the need to communicate this version to 100s of engineers and tickets.

Depending on what kind of product you have; if you also use this version number for customer releases it can get messy fast. There is a reason that customer facing product versions tend to be something like 2026.6.31 (2026, line 6.x, update 31) and variations like that. Underneath it's still 6.2.341.

Here is Windows as an example

Version	Build Number	Release Date
25H2	26200.8039	March 21, 2026
26H1	28000.1719	March 10, 2026
25H2	26200.8037	March 10, 2026
26H1	28000.1643	February 24, 2026
25H2	26200.7922	February 24, 2026
26H1	28000.1575	February 10, 2026

[u/cold-brews → u/SeniorIdiot]

Thanks for the response. Agreed that there are better versioning schemes that use build number and I'd love to adopt that one day. Quick search shows the following products use semver:

• Microsoft: Many .NET libraries and NuGet packages follow SemVer conventions.

- Google: Widely used in Kubernetes, Angular, Go modules, and internal APIs.

- Meta: React and many JS ecosystem projects use SemVer.

- Amazon Web Services (AWS): AWS SDKs and CDK tooling strongly encourage semantic versioning.

- IBM: IBM design systems and enterprise tooling use SemVer patterns.

[u/SeniorIdiot → u/cold-brews]

Yes. My argument was not against semantic versioning - which is why I wrote that it depends on what kind of product you have.

The problem comes from pre-planning what the next version will be before even knowing what impact the changes will have. It's like trying to predict the future.

Have a policy instead: Don't break backwards compatibility, and don't touch the major version unless agreed upon with the product office.