Is fast major version bumping an evidence of poor design?

Question

I started a job as junior programmer a few months ago. The system we are working on has been in production for ~2 years. I wasn't involved in the begging of the system and the design.

One thing I have noticed is that the system major version is already 11.Y.Z. Form my experience working with other systems and libraries, I don't recall seeing a product bumping major version that fast. There are products that have been for years in 1.X.Y, and still receiving features and bugfixes.

Assuming that the semantic versioning is used properly, does this indicate that the system is poorly designed since it makes major breaking changes almost every four months?

Answer 1

Assuming that the semantic versioning is used properly, does this indicate that the system is poorly designed since it makes major breaking changes almost every four months?

Not necessarily.

You mentioned in the comments that this is an internal API. Breaking an API is bad, because you break everybody's code. But for an internal API "everybody" is just "you", and you are perfectly capable of coordinating such API changes with yourself, so the pain that is usually associated with API changes is much less worse.

Also, the average could be massively misleading: maybe they had 11 breaking API changes during the first couple of days of early development and have been stable for 4 years ever since? SemVer does allow you to make breaking changes without increasing the major number if the major number is 0, but it doesn't force you to. Maybe they started using SemVer from day 0, even during the prototyping / exploratory phases?

Answer 2

Short answer

No

Long answer

"Sometimes a number is just a number"

Forget about "semantic versioning", "rationality", "logic" in current crazy world

Why does Chrome gobble up version numbers so quickly?

the "version" numbers are used as Milestones for the branch points, not Major Releases to wow the public the way other developers use them. And it's an ongoing development flow, with features ready or not ready, rather than an occasional event bringing together many new features to make a big event

Answer 3

When using semantic versioning, there still is the decision to be made which changes are considered "major", and which are "minor". There are various reasons to bump the version number - or to not bump it.

Systems with backward compatibility promises might end up bumping up the major version number with most updates, just because there is a backward compatibility break in some more or less esoteric corner case. The same systems might up sticking to 1.x.y almost indefinately, because a lot of effort is put into backward compatibility, trying to never break any dependant system. Both approaches to version numbering could be considered "conservative", but both could also be a sign of a deep underlying problem.

Other times, you actually have a release schedule (think of quarterly update CDs sent out to customers) where it makes sense to change the major version number, so that instead of "Version 3.4 / Oct 16" it just says "Version 11.0". Nowadays, more and more software is released in short intervals, making release schedules less of a reason to stick to a specific versioning scheme. I've seen this in big warehouse systems that allow internal IT only one day of downtime a quarter (usually a sunday). This day is the deployment day and is marked with a new major version every time.

Some programs have external dependancies that are of uttermost importance, because the user will have to update both at the same time. If you have a Word-addon that only works with Word 2010 and another one for Word 2013, you may wish to synchronise your major version numbers to that of MS-Word. Here, major numbers are so important, because some of your users will be "behind" your normal update schedule, since they haven't updated to the most current version of Word (or whatever else you're relying upon: SAP, Dynamics, etc).

Sometimes, other external factors dictate version numbers. If you have fiscal software, there might be annual updates corresponding to tax law (which tends to come into effect on Jan 1st). Such systems will have major versions changing exactly once a year - not because that is the update schedule, but because that is of other importance to the customer: If you do your 2016 taxes, you better have program that is updated to 2016 tax law.

In the end, version numbers are dependant on so many factors - often specific to one domain - that the number alone does not tell you anything about the state of your codebase. It is a much better approach to look at when, why and how deployments happen - and how smoothly that goes. If you can roll out a major update to 10.000 customers and have a couple of phone calls - you're probably fine. If you roll out a minor patch to 10 customers and have to work overtime because of that, something is probably wrong.

Answer 4

The concensus on the meaning of version numbers is indeed major.minor.revision.buildnumber

If major goes up quickly it could just be the developer has all these new ideas and works really hard.

In the business world however there may be other reasons for incrementing the major version number. Like

• Sales are down, clients/users are waiting for the next big major release before upgrading.

• The contract says clients are entitled to minor updates. The vendor cannot charge them for those so some minor improvement is sold as a major product upgrade.

• Competitor X has been in the game a bit longer so their major version number just happens to be higher than yours. This makes it look like you are lagging behind, you have to "catch up".