Hi Mark,
ideally, we would like to use a single repository with the following
constraints :
- all Open MPI developers can commit to the master
- only Release Manager and Gatekeepers can commit to the release branch
(v1.8, ...)
unfortunatly, github does not (yet ?) implement per branch access
control list (ACL)
and this is the only reason why we have to use (at least) two repositories :
ompi for the master branch and ompi-release for the releases (v1.8, ...)
branch
This is unfortunate and independent of the new release process described
by Jeff,
and my guess is we will move to a single repository as soon as github
implements
per branch ACL
Cheers,
Gilles
On 5/19/2015 6:03 AM, Mark Santcroos wrote:
Hi Jeff, all,
Thanks for bringing this to the wider community.
I hope this will eventually address my main concern: the relatively old versions that get
deployed on HPC systems around the world, which I assume is/was because of the "odd
;-)" numbering.
What I didn't see in the doc, will you continue to work with two repo's or will
that change too?
(I found that confusing as a newcomer)
Regards,
Mark
On 18 May 2015, at 21:11 , Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:
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><ompi-release-process-proposal-public.pdf>_______________________________________________
devel mailing list
de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post:
http://www.open-mpi.org/community/lists/devel/2015/05/17414.php
_______________________________________________
devel mailing list
de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post:
http://www.open-mpi.org/community/lists/devel/2015/05/17415.php
