This is not a very technical question, but I'm having trouble finding any information about it. I often use CPLEX to solve my power system planning problems. I just noticed that CPLEX suddenly jumped from version 12.10.0 (December 2019) to 20.1.0 (December 2020) (see Wikipedia and IBM's documentation website). Does anyone know why IBM skipped over versions 13-19? Is there something radically different about version 20?
$\begingroup$
$\endgroup$
2
-
7$\begingroup$ CPLEX 12.0 was released in 2009. Then they went up by 0.1 for annual or so new releases with new features. They even had a 12.6.0, 12.6.0 fixpack with some new features, 12.6.1, 12.6.2, 12.6.3 all with new features. Then 12.7.0, 12.7.1, 12.8, 12.9, 12.10 (in 2019), before finally skipping to 20.1. Maybe they now want the first field to be the year? I don't think there was any bigger change between 12.10 and 20.1 than if 20.1 had been called 12.11 or 13.0. Why did they get so bogged down in the 12's? And why 20.1 and not 20.0 - maybe 1st decimal place i is ith release of the year? $\endgroup$– Mark L. StoneCommented Apr 1, 2021 at 23:50
-
$\begingroup$ For more info about Calendar Versioning: calver.org $\endgroup$– StradivariCommented Apr 2, 2021 at 18:48
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
3
I don't know why the version number jumped. I will say that I found the creeping pace documented in Mark's comment odd from a marketing perspective -- it might lead a consumer to think IBM was just patching the occasional bug while competitors (with faster moving version numbers) were making technological "leaps". Maybe someone at IBM had the same thought?
As for the last question, no, I would not say there is anything radically different about 20.1. There are one or two new features (which I cannot recall offhand), but my use of it has not changed in any fundamental way from what I was doing with 12.10.
-
2$\begingroup$ Why can't everyone just stick with Apache version guildelines? MAJOR.MINOR.HOTFIX: if the MAJOR version changes, it breaks backwards compatibility. If the MINOR version changes, features are added. If the HOTFIX version changes, it fixes bugs. That's simple, clear and reliable. $\endgroup$ Commented Apr 9, 2021 at 8:32
-
1$\begingroup$ From a technological standpoint, I would agree. Note, though, that the Apache guidelines seem to have been developed for libraries rather than commercial products. I suspect the marketing people for the latter want the major version ticking upward periodically to keep the product looking "current", "state of the art" or whatever. $\endgroup$– prubin ♦Commented Apr 9, 2021 at 20:42
-
1$\begingroup$ Yes, that's common. Although I'd argue it's not all marketing people. Only marketing and engineering that think short-term. Then you get situations like "Windows 95 is older than Windows 10". Or Weblogic 8.1, which skipped Weblogic 8.0 because their users didn't buy ".0" versions. $\endgroup$ Commented Apr 12, 2021 at 9:30
$\begingroup$
$\endgroup$
3
This can be one of two things: (i) they changed their versioning system from Semantic Versioning to Calendar Versioning (e.g. they are now following the calendar so CPLEX 20 stands for "2020"), or (ii) the new release is a major release.
Since calendar versioning is self-explanatory, I'll explain what major releases are, since we use the same system at Octeract.
Contrary to intuition, a "major" release does not imply that some new major feature has been introduced.
What it does imply is that there has been a breaking change in the API of the software that is not backwards compatible.
For instance, the bump from Python 2.7 to Python 3 was a major release, which broke existing Python 2.7 code. This was marked by the bump from 2 to 3. This is a convention that nearly all professional developers are familiar with.
Note that introducing a "breaking" change doesn't mean that everything is broken (although in some cases it does, like Python broke print), it's just the developer's way of saying that this will no longer interact with other software in quite the same way it used to.
Now, applying Occam's razor here to see what happened with CPLEX, (i) it's highly unlikely that they broke backwards compatibility for an enterprise product, and (ii) it's too much of a coincidence that out of all numbers they chose "20" for the December 2020 release, therefore my money would be on them having changed their versioning to track the calendar year.
Now why did they do that out of the blue? Well, if you have been following some of their staff on Twitter you might connect the dots. From a developer's point of view, my guess is something that I am always a bit sad to see happen in mature software: such a switch often indicates that management has decided that the API is what it is, and they've switched to maintenance mode with no foreseeable plans to improve it.
-
$\begingroup$ An anonymous source with inside information confirms that they switched to calendar year for the "major" version and release number for the "minor" version. The old plan changed major versions only if the API changed substantially, which the dev team tried not to do, hence all the 12.xx versions. Another thing the source mentioned, which had not occurred to me, is that major version = calendar year makes it easier to predict the version in which a deprecated feature becomes extinct. $\endgroup$– prubin ♦Commented Apr 13, 2021 at 15:13
-
$\begingroup$ @prubin That's great to know :) Just curious, doesn't this mean that they don't plan to break the API anymore? $\endgroup$ Commented Apr 13, 2021 at 16:26
-
$\begingroup$ I wouldn't go that far (at least if "break" means "alter"). I'm not privy to their plans, but my impression is that when they added the generic callbacks the plan was to deprecate and eventually remove the "legacy" callbacks. Similarly, they revamped the class structure for parameters in the Java API and deprecated a lot of old names. I'm not sure whether the old names are fully removed yet, but if not presumably they will be. $\endgroup$– prubin ♦Commented Apr 14, 2021 at 17:47