This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
The Open MPI development team would like to announce a change in its
release methodology. Starting with the v1.3 series, the second digit
in the Open MPI version number will carry additional significance:
* _Even_ minor release numbers are part of "super-stable" release
series (e.g., v1.4.x). Releases in super stable series are well-
tested, time-tested, and mature. Such releases are recomended for
production sites. Changes between subsequent releases in super stable
series are expected to be fairly small.
* _Odd_ minor release numbers are part of "feature" release series
(e.g., 1.3.x). Releases in feature releases are well-tested, but they
are not necessarily time-tested or as mature as super stable releases.
Changes between subsequent releases in feature series may be large.
Feature releases are expected to be "somewhat frequent".
Much more is explained on this wiki page: https://svn.open-mpi.org/trac/ompi/wiki/ReleaseMethodology
(some of the text below is taken from the wiki page cited above)
We have [at least] 2 competing forces in Open MPI:
1. desire to release new features quickly. Fast is good.
2. desire to release based on production quality. Slow is good.
The competition between these two forces has both created some tension
in the Open MPI community as well as created a Very Long release cycle
for OMPI v1.3 (yes, it was our specific and deliberate choice to be
feature driven for v1.3 -- but it was still verrrrry loooong). Prior
to the v1.3 series, we did not manage these competing forces well. We
have come to realize that we should embrace both of these forces
simultaneously, drawing inspiration from other well-established
software release paradigms, such as:
* Linux kernel "odd/even" version number release methodology
* Red Hat/Fedora stable vs. feature releases
* Agile development models
Starting with the v1.3 series (although it wasn't formally decided
until after v1.3.0 was released), Open MPI will have two concurrent
1. "Super stable": for production users who care about stability
above all else. They're willing to wait long periods of time before
updating to a new version of Open MPI. Super Stable release series
will have an even minor version number.
2. "Feature driven": for users who are willing to take a few
chances to get new OMPI features -- but cannot endure the chaos of
nightly trunk tarballs. Feature release series will have an odd minor
version number. Feature releases are expected to be "somewhat
frequent"; probably no more often than once a month and no less often
than once every three months.
A typical release cycle starts with a "feature" series that eventually
morphs into a "super stable" stable series. Changes may be large
between subreleases in feature series, while changes are expected to
be fairly small in super stable subreleases.
To bootstrap applying this release methodology to Open MPI:
1. After the v1.3 series was released, it was declared a Feature
* A small number of important features will be developed for
the v1.3 series in subsequent v1.3.x releases.
* The v1.3 series will then morph into its Super Stable
counterpart (v1.4) and only accept bug fixes
2. The v1.5 will branch from the development trunk and start
working towards a v1.5.0 Feature release and eventual v1.6.0 Super
The wiki page contains more details: https://svn.open-mpi.org/trac/ompi/wiki/ReleaseMethodology