Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-10-15 13:56:51


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.bell_at_[hidden]
> (QLogic Host Solutions Group, formerly Pathscale)
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

-- 
Jeff Squyres
Cisco Systems