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. I'm only guessing here so don't take my word for it, but as a developer I am always a bit sad when this happens in mature software, as it 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.

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.

This can be one of two things: (i) they changed their versioning system (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. I'm only guessing here so don't take my word for it, but as a developer I am always a bit sad when this happens in mature software, as it 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.

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. I'm only guessing here so don't take my word for it, but as a developer I am always a bit sad when this happens in mature software, as it 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.