This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
> After starting, we decided that changing the MCA base revision number
> to 2.0.0 also meant changing *ALL* the framework version numbers.
> This is because the same components from framework <foo> compiled with
> MCA base version 1.x.x would not be binary compatible when compiled
> with MCA base version 2.0.0 (the mca_base_component_t struct is a
> different size, for example). So it seemed like we needed to make a
> large change: we changed both the MCA base and every framework
> interface version to v2.0.0, which entails touching every framework
> base and every component.
I guess I don't understand. I thought there were three versions in every
component -- the MCA version, the framework version, and the component
version. The first two should determine if the component can safely be
loaded and the third is to identify the component. I agree that for this
change (an MCA-level change), the MCA version *should* change. However,
the framework interface didn't change (well, not as a result of this
change), meaning that the framework version *should not* change. The MCA
load infrastructure should see that the MCA versions don't match, and not
load the component.
Or am I missing something here?