Proposed new PMIx/PRRTE roadmap
9 views
Skip to first unread message
Ralph Castain
Nov 11, 2025, 7:11:11 PMNov 11
to pm...@googlegroups.com
Hello all
I have been looking at the overall situation with respect to PMIx and PRRTE releases, and believe that a change in release strategy is warranted. Frankly, it is becoming a little too burdensome to support multiple release branches, and our release cadence has been too frequent. It’s nice to be responsive, but it places a burden on our downstream packagers (as well as on myself).
Looking at root causes, it becomes pretty apparent that some of the problem lies in a lack of sufficient pre-release testing. We have too many consumers that wait until we actually generate a formal release before trying the new version - and then immediately request an update when they find a problem. This is not a sustainable ecosystem.
So I am proposing to make a few changes:
* There will be no more releases from the PMIx v5.0.x series - we are done. I have a cleanup “sweep” release in preparation that will include all bug fixes since the last formal release - this should resolve all problems reported to-date.
* There will be no more releases in the PMIx v6.0.x series. The changes since v6.0.0 involve new server interfaces and some significant infrastructure modifications - probably not appropriate for a bug fix release. Since bug fixes in master are intertwined with those changes (especially the infrastructure mods), it likely is too much effort to create backports for them.
* We will start a new v7.0 series that will be the final release series of the project. This will likely occur in 1Q26, though no promises. I am tracking completion here: https://github.com/openpmix/openpmix/issues/3715 and https://github.com/openpmix/prrte/issues/2302. Since the two projects are connected, neither project will be released until both projects are "complete”.
* Once PMIx v7.0 and PRRTE v5.0 are out, all bug reports on prior series will (a) be fixed in the new series, if they still exist there; and (b) will return an advisement to upgrade. Fixes will not be backported to earlier releases.
* Releases will occur no more often than every 3 months - i.e., a new release will only be allowed out once per quarter. People are welcome to pull the Git repo branch if they need something in the interim.
The success of this proposal hinges on getting people to test pre-release candidates. Since our release cadence will be locked to once per quarter or less, fixes for problems found after release will be SLOW - so you have an incentive to test when requested or (even better) setup and run a continuous test protocol. If you wish, you are welcome to submit a Git workflow for this purpose - I’m happy to add it to our repo.
While this is not yet cast in stone, I expect it to be adopted in the not-so-distant future. Any comments/thoughts are welcome in the meantime!
Ralph
I have been looking at the overall situation with respect to PMIx and PRRTE releases, and believe that a change in release strategy is warranted. Frankly, it is becoming a little too burdensome to support multiple release branches, and our release cadence has been too frequent. It’s nice to be responsive, but it places a burden on our downstream packagers (as well as on myself).
Looking at root causes, it becomes pretty apparent that some of the problem lies in a lack of sufficient pre-release testing. We have too many consumers that wait until we actually generate a formal release before trying the new version - and then immediately request an update when they find a problem. This is not a sustainable ecosystem.
So I am proposing to make a few changes:
* There will be no more releases from the PMIx v5.0.x series - we are done. I have a cleanup “sweep” release in preparation that will include all bug fixes since the last formal release - this should resolve all problems reported to-date.
* There will be no more releases in the PMIx v6.0.x series. The changes since v6.0.0 involve new server interfaces and some significant infrastructure modifications - probably not appropriate for a bug fix release. Since bug fixes in master are intertwined with those changes (especially the infrastructure mods), it likely is too much effort to create backports for them.
* We will start a new v7.0 series that will be the final release series of the project. This will likely occur in 1Q26, though no promises. I am tracking completion here: https://github.com/openpmix/openpmix/issues/3715 and https://github.com/openpmix/prrte/issues/2302. Since the two projects are connected, neither project will be released until both projects are "complete”.
* Once PMIx v7.0 and PRRTE v5.0 are out, all bug reports on prior series will (a) be fixed in the new series, if they still exist there; and (b) will return an advisement to upgrade. Fixes will not be backported to earlier releases.
* Releases will occur no more often than every 3 months - i.e., a new release will only be allowed out once per quarter. People are welcome to pull the Git repo branch if they need something in the interim.
The success of this proposal hinges on getting people to test pre-release candidates. Since our release cadence will be locked to once per quarter or less, fixes for problems found after release will be SLOW - so you have an incentive to test when requested or (even better) setup and run a continuous test protocol. If you wish, you are welcome to submit a Git workflow for this purpose - I’m happy to add it to our repo.
While this is not yet cast in stone, I expect it to be adopted in the not-so-distant future. Any comments/thoughts are welcome in the meantime!
Ralph
Reply all
Reply to author
Forward
0 new messages