OMPI supports multiple different repository systems (SVN, hg, git).
But the VERSION file has listed "want_svn" and "svn_r" as fields, even
though the actual repo system and version may not be SVN.
So search/replace those fields (and derrivative values that come from
those fields) with "want_repo_rev" and "repo_rev", respectively.
This commit was SVN r24405.
versioning by assuming that 1.3.3 was released as 0:0:0. The next
release (1.3.4 or 1.4 or whatever it is) will be the first to
programatically set these valuess (and it'll likely be something
beyond 0:0:0 for at least some of the libraries).
This commit was SVN r21732.
note in VERSION file.
NOTE: the versions will ''always'' be 0:0:0 on the SVN trunk and
developer branches. They will only have meaningful values (starting
with 0:0:0 in 1.3.4) on release branches. Only RM's will modify these
values immediately preceeding a release.
This commit was SVN r21729.
versions, dates and build names.
Fixes trac:1387
Big thanks to Jeff and Brian for help and oversight.
This commit was SVN r19120.
The following Trac tickets were found above:
Ticket 1387 --> https://svn.open-mpi.org/trac/ompi/ticket/1387
a random string of characters as part of the version number (the really
soon to happen 1.0lanl release and the 1.1sc2005 release that we've
talked about). So rather than having alpha and beta fields that must
be numeric values, have a general field that can be any alphanumeric
value.
This commit was SVN r7511.
more obvious (and documented)
- VERSION now has lots of comments in it
- separate out whether we want the SVN r number in the version and
what the SVN r number is
- clearly describe the process for building the full version number
string
- make ompi info have a separate line item specifically for the SVN r
number, regardless of what the version number is
- update "make dist" process to substitute in the SVN r version
This commit was SVN r5022.
