Devel community -- Over the past few weeks, the core Open MPI members have been internally discussing a proposal to change to the version numbering of Open MPI public releases. We've reached internal consensus, and would like to present this to the larger community for feedback.
Here's the short version: 1. No longer use an "odd/even" release strategy: *all* releases will be good/stable releases. 2. (Still) Use a MAJOR.MINOR.RELEASE version triple: - When we fork a new release branch from master, we bump the MAJOR number. - When we add new features, we bump the MINOR number. - All other releases bump the RELEASE number. 3. Backwards compatibility will (still) be preserved for the duration of an entire release branch (i.e., for all versions with a common MAJOR number). 4. Release series (i.e., releases with the same MAJOR number) aim to have active development for about 1 year (i.e., new features, etc.). They will continue to be supported (i.e., have bug-fix releases) for about a year after that. 5. We aim to fork from master for a new MAJOR series about once a year. 6. The v1.8 series will still abide by the "old" version numbering scheme (i.e., only bug fixes applied to future v1.8.x releases). Here's more detail: See the attached slides. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
ompi-release-process-proposal-public.pptx
Description: ompi-release-process-proposal-public.pptx
ompi-release-process-proposal-public.pdf
Description: ompi-release-process-proposal-public.pdf
