Ok, having read the libtool docs now, I see why the release number is
a bad idea. :-)
I'm assuming that:
- The libmpi interface will rarely change, but we may add to it over
time (there's a specific point about this in the libtool docs -- no
problem)
- The libopen-rte interface historically has had major changes
between major releases and may have interface changes between minor
releases, too
- The libopen-pal interface is relatively stable -- I actually
haven't been checking how often it changes
So if we do this, I think the RM's would need to be responsible for
marshaling this information and setting the appropriate values. I
can convert the build system to do use this kind of information; the
real question is whether the community wants to utilize it or not
(and whether the RM's will take on the responsibility of gathering
this data for each release).
On Oct 15, 2007, at 1:16 PM, Christian Bell wrote:
On Mon, 15 Oct 2007, Brian Barrett wrote:
Nooooo! :)
It would be good for everyone to read the Libtool documentation to
see why versioning on the release number would be a really bad idea.
Then comment. But my opinion would be that you should change based
on interface changes, not based on release numbers.
Yes, I second Brian. Notwithstanding what the popular vote is on MPI
ABI compatibility across MPI implementations, I think that
major/minor numbering within an implementation should be used to
indiciate when interfaces break, not give hints as to what release
they pertain to.
. . christian
--
christian.b...@qlogic.com
(QLogic Host Solutions Group, formerly Pathscale)
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
