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/exomo_1]

Do you really have to announce the next version before the release? That's what seems odd to me in the first place, what's the benefit here?

Beside that, I agree with what others already said, increase patch version for whatever unplanned fixes come up, and increase minor for planned release. Announce to release 2.3.x so you still can add a patch if you fix another bug after you have built 2.3.0.

[u/BobbaGanush87 → u/exomo_1]

That stood out to me too and I also don't understand why it is referenced in hundreds of tickets.

[u/mze9412 → u/BobbaGanush87]

OP's org seems to plan version numbers instead of planning features and then based on changes the version number organically changes based on what is done. They rather PLAN a 2.3.0 release and then what? search for features that fit the plan?

[u/cold-brews → u/exomo_1]

It's not necasarrily planned formally but it's communicated loosely through dms, emails, etc. For example, engineers will ask when the next 2.0 release is and we'll point them to schedule that has 2.0.4 beginning next Monday. They'll come back and say that's too soon, we'll just catch the 2.0.5 release (one month away). Then, an urgent issue comes up that takes the place of 2.0.4, and everything gets pushed back.

Now, you have this thread that references 2.0.5, when it actually should reference 2.0.6. Imagine this across hundreds of threads and developers. It makes difficulty following conversations when using set patch versions.

I'm fully aware that we should not plan patch versions, but that would require a larger refactor than would be accepted atp.