16

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?

  • 2
    That question will depend on whether those major breaking changes bring enough benefits (and profits) that justify the high rate of change. – rwong Mar 11 '17 at 16:42
  • 3
    If that version number uses Semver, and if the system has a library or other API that other teams or organizations depend on, then this high major number means that there have been problems to commit to a stable, extensible API design. It also means that clearly communicating incompatibilities is highly valued which is a good thing. For anything else (like marketing names, application programs, non-Semver numbers, …) the number is meaningless and should be largely disregarded. Just ask your coworkers about this, as part of you getting to know the project better. – amon Mar 11 '17 at 17:34
  • 3
    @amon The system is used internally with public mobile clients communicating with the system via REST-like API. The versioning is Semver as I mentioned and not marketing version. – user367035 Mar 11 '17 at 17:52
  • Number doesn't matter, but I would get suspicious if the version identifier included some cute acronym, like Windows NT or Windows ME or XP or really Windows anything. – John Wu Mar 11 '17 at 22:04
  • 1
    @JohnWu: the question is specifically about the number, so, yes, the number does matter. More precisely, it is about the number in the context of SemVer, where the number not only does matter, but also has a precisely-specified meaning. – Jörg W Mittag Mar 12 '17 at 11:01
14

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?

  • 5
    This answer seems to directly address the question. Some of the other answers would be valid if not for OP's assumption of semantic versioning. – joshp Mar 12 '17 at 17:04
  • Also notable is that breaking changes aren't always major. Sometimes they're really quite small (yet important). So they could need very little change for the users. Also, there can be quite a large degree of breaking changes depending on how the API is used. Sometimes a breaking change won't affect all users, for example. Also, bug fixes can introduce breaking changes, yet it's ideal to fix these sooner rather than later. And if the API is internal, then it's a lot easier to handle these small breaking changes. – Kat Mar 14 '17 at 18:12
1

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

  • 7
    The OP has said that they are using semantic versioning; why do you then ignore it? – Jörg W Mittag Mar 12 '17 at 10:58
-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.

  • 3
    "When using semantic versioning, there still is the decision to be made which changes are considered "major", and which are "minor"." – No, there isn't; that is precisely defined in the specification. "There are various reasons to bump the version number - or to not bump it." – No, there aren't; there is precisely one reason to increase the major number (which this question is about), and it is defined precisely in the spec. – Jörg W Mittag Mar 12 '17 at 19:46
  • 1
    @JörgWMittag Either I'm reading it wrong, or the spec specifically says when you MUST bump the version numbers, but it says nothing about when you MAY. – Hazzit Mar 13 '17 at 13:35
-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".

  • 6
    The question is tagged with semantic-versioning, the OP mentions semantic versioning in the question, and has re-affirmed in the comments that they are using semantic versioning. The SemVer specification says very clearly when major versions are incremented. None of your "other reasons" apply. – Jörg W Mittag Mar 12 '17 at 11:00

protected by gnat Mar 12 '17 at 19:25

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.