Correct.
There is a single "v2.x" branch that was branched from master a while ago (I
didn't check, but I assume the hash Gilles cites below is correct). v2.0.0 is
tagged on that branch.
Git branches and v2.0.x and v2.x plans were a topic we discussed in the
face-to-face meeting in Dallas last week. Here's a summary...
Soon, we will be doing the following:
- release v2.0.1 from the v2.x branch and tag it in git
- merge in v2.0.2 PRs (which should all be low risk)
- merge in low risk v2.1.0 PRs that do not have conflicts (some are quite old)
- freeze the ompi-release repo
- remove everyone's write permissions
- ask PR authors to re-create their PRs on the ompi repo
- merge all the branches in ompi-release back in to ompi
- (possibly) "git rm -rf" everything in all ompi-release branches, and
leave a single README.md saying "Everything is in the ompi repo now"
--> Sidenote: when we moved to Github, we initially created the ompi and
ompi-release repos because Github did not originally support per-branch ACLs.
Now they do, so once we hit a natural development break point (i.e., after
v2.0.1), we can finally merge ompi-release back into ompi and work solely out
of a single git repo. Yay!
(...at this point, the v2.x branch will be in ompi...)
- create branch v2.0.x from v2.x
- update VERSION on v2.0.x to be v2.0.2a1
- update VERSION on v2.x to be v2.1.0a1
Does that make sense?
> On Aug 25, 2016, at 1:10 AM, Gilles Gouaillardet <gil...@rist.or.jp> wrote:
>
> If my git is correct
>
> $ git rev-list --boundary v2.x...master/master | grep '^-'
> -acc2c7937cd3b50de16044b673399e4c4a7456bc
> -6772d32b85b836438eeca72e4a8fda026ea67a55
> -ec44a25070f99b6e1d96886fe3990ad560ee63c0
>
>
> $ git show ec44a25070f99b6e1d96886fe3990ad560ee63c0
> commit ec44a25070f99b6e1d96886fe3990ad560ee63c0
> Author: Jeff Squyres <jsquy...@cisco.com>
> Date: Fri Jun 19 13:32:18 2015 -0700
>
> README: clarify OMPI's same-version requirements
>
> Clarify that Open MPI requires the exact same version number in all
> parts of an Open MPI / OSHMEM job for it to work properly.
>
> the v2.x branch was forked from master at commit
> ec44a25070f99b6e1d96886fe3990ad560ee63c0
>
> then v2.x was updated and v2.0.0 and v2.0.1rc1 were released from that branch.
>
>
> Cheers,
>
>
> Gilles
>
> On 8/25/2016 1:55 PM, Sreenidhi Bharathkar Ramesh via devel wrote:
>> Hi,
>>
>> With respect to "master" branch, from which commit is v2.0.1 branched off ?
>> Please let me know.
>>
>> Thanks,
>> - Sreenidhi.
>>
>> On Tue, Aug 23, 2016 at 2:59 AM, r...@open-mpi.org <r...@open-mpi.org> wrote:
>>> Hello folks
>>>
>>> Dunno where the head-honcho’s are hiding, but per their request: the newest
>>> v2.0.1 release candidate has been posted in the usual place:
>>>
>>> https://www.open-mpi.org/software/ompi/v2.0/
>>>
>>> Beat it up, please!
>>> Ralph
>>>
>>> 2.0.1 -- 23 August 2016
>>> -----------------------
>>>
>>> Bug fixes/minor improvements:
>>>
>>> - Short message latency and message rate performance improvements for
>>> all transports.
>>> - Fix shared memory performance when using RDMA-capable networks.
>>> Thanks to Tetsuya Mishima and Christoph Niethammer for reporting.
>>> - Fix OpenSHMEM crash when running on non-Mellanox MXM-based networks.
>>> Thanks to Debendra Das for reporting the issue.
>>> - Fix various runtime issues by updating the PMIx internal component
>>> to v1.15.
>>> - Fix process startup failures on Intel MIC platforms due to very
>>> large entries in /proc/mounts.
>>> - Fix a problem with use of relative path for specifing executables to
>>> mpirun/oshrun. Thanks to David Schneider for reporting.
>>> - Various improvements when running over portals-based networks.
>>> - Fix thread-based race conditions with GNI-based networks.
>>> - Fix a problem with MPI_FILE_CLOSE and MPI_FILE_SET_SIZE. Thanks
>>> to Cihan Altinay for reporting.
>>> - Remove all use of rand(3) from within Open MPI so as not to perturb
>>> applications use of it. Thanks to Matias Cabral and Noel Rycroft
>>> for reporting.
>>> - Fix types for MPI_UNWEIGHTED and MPI_WEIGHTS_EMPTY. Thanks to
>>> Lisandro Dalcin for reporting.
>>> - Correctly report the name of MPI_INTEGER16.
>>> - Add some missing MPI constants to the Fortran bindings.
>>> - Fixed compile error when configuring Open MPI with --enable-timing.
>>> - Correctly set the shared library version of libompitrace.so. Thanks
>>> to Alastair McKinstry for reporting.
>>> - Fix errors in the MPI_RPUT, MPI_RGET, MPI_RACCUMULATE, and
>>> MPI_RGET_ACCUMULATE Fortran bindings. Thanks to Alfio Lazzaro and
>>> Joost VandeVondele for tracking this down.
>>> - Fix problems with use of derived datatypes in non-blocking
>>> collectives. Thanks to Yuki Matsumoto for reporting.
>>> - Fix problems with OpenSHMEM header files when using CMake. Thanks to
>>> Paul Kapinos for reporting the issue.
>>> - Fix problem with use use of non-zero lower bound datatypes in
>>> collectives. Thanks to Hristo Iliev for reporting.
>>> - Fix a problem with memory allocation within MPI_GROUP_INTERSECTION.
>>> Thanks to Lisandro Dalcin for reporting.
>>> - Fix an issue with MPI_ALLGATHER for communicators that don't consist
>>> of two ranks. Thanks to David Love for reporting.
>>> - Various fixes for collectives when used with esoteric MPI datatypes.
>>> - Fixed corner cases of handling DARRAY and HINDEXED_BLOCK datatypes.
>>> - Fix a problem with filesystem type check for OpenBSD.
>>> Thanks to Paul Hargrove for reporting.
>>> - Fix some debug input within Open MPI internal functions. Thanks to
>>> Durga Choudhury for reporting.
>>> - Fix a typo in a configury help message. Thanks to Paul Hargrove for
>>> reporting.
>>> - Correctly support MPI_IN_PLACE in MPI_[I]ALLTOALL[V|W] and
>>> MPI_[I]EXSCAN.
>>>
>>> Known issues (to be addressed in v2.0.2):
>>>
>>> - See the list of fixes slated for v2.0.2 here:
>>> https://github.com/open-mpi/ompi/milestone/20, and
>>> https://github.com/open-mpi/ompi-release/milestone/19
>>> (note that the "ompi-release" Github repo will be folded/absorbed
>>> into the "ompi" Github repo at some point in the future)
>>>
>>> - ompi-release#1014: Do not return MPI_ERR_PENDING from collectives
>>> - ompi-release#1215: Fix configure to support the NAG Fortran compiler
>>>
>>> Known issues (to be addressed in v2.1):
>>>
>>> - ompi-release#987: Fix OMPIO performance on Lustre
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel@lists.open-mpi.org
>>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
