Open MPI recently updated its version numbering scheme and development roadmap.
This new scheme aims to provide more semantic information in the Open MPI “A.B.C” version number to both end users and system administrators.
There are a number of details worth understanding about the new version number scheme, but we recognize that many people won’t want to read a detailed description of the plan. So here’s the TL;DR version:
- Starting with v1.10.0:
- No more odd/even series.
- “Version A.B.C”: each number now has a specific meaning. You should read the NEWS file when “A” changes.
- The intent is to release new features faster.
- Aim to limit life release series.
- Approximately one year of development + approximately one year of bug fixes.
For those of you wanting to see more detail, the following slides explain things more fully:
Thanks! This is an excellent idea and very precisely described.
Makes a lot of sense. See also http://semver.org/ .
One concern though: 1.10.0 is lexicographically smaller than 1.8.x. Expect issues with that in some contexts.
In my mind, you should start using this scheme with 2.0, which could mean “start of new versioning scheme”. People will forgive you if this doesn’t include backward incompatible changes (or you could treat the new versioning scheme as a backward incompatible change).
You’r right — this scheme is heavily influenced by sever.org. 🙂
FWIW: We talked about the “10” vs. “8” and decided that we would use “10” anyway; it’s basically a tradeoff we deliberately chose to do.
In short, we had already planned for 2 major things:
1. A follow-on to the v1.8 series with a small number of new features (since new features were not allowed in the v1.8 series — these were basically “pent up” vendor features). But it’s still a “small” change on top of the v1.8 series, and it didn’t seem worthwhile to give it a major new number like “2.0”. Hence, we chose “1.10” (and also for the reasons I cited in the slides).
2. A re-branch from the development master to initiate a whole new major release series. This branch seemed worthy of a “large” number change (i.e., to “2.0.0”).
As such, the numbers “v1.10.0” and “v2.0.0” kinda fit into our already-existing plans.
Hope that made sense!