To some extent, I think that binary compatibility between sub-modules matters. Let's assume that (this is a scenario that I am considering; any ressemblance is pure coincidence):
* I run M3;
* EJB is allegedegly broken; and
* I am happy with the other service stack.
Should I upgrade to M4, where EJB is fixed? Or, should I partially upgrade openejb-core and openejb-builder if I know that they are binary compatible with the depending sub-modules?
Another scenario is where a newer version of a given sub-module brings additional capabilities that I badly want. Also, in this case, I will only partially update.
It seems that binary compatibility is only a part of the overall picture if one wants to support forward-portability of backed configurations. Let's assume that I have a configuration defining a CMP 2.x deployment. This configuration contains a bunch of serialized CMPField instances. I want to upgrade to a newer server version defining a CMPField class with an additional field. I think that we will face some serialization incompatibilities when reading back the GBean state.
I agree: I'm happy to worry about that way way way further down the road.
Thanks, Gianny
On 5/04/2005 4:17 AM, Dain Sundstrom wrote:
I personally think this is way way way too early to be worried about binary compatability between configuration objects build with pervious releases and builds. Also, are you taking only about the official M1, M2 and M3 releases or builds from code?
What do you, the community, think about us spending time thinking about binary compatibility between milestone releases?
-dain
-- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
On Apr 4, 2005, at 3:08 AM, Gianny Damour wrote:
My bad :(
I must admit that this is a side effect that I have not duly considered. I considered the source and binary compatibility and I missed this serialization specific incompatibility.
Gianny
On 3/04/2005 6:15 AM, Jeremy Boynes wrote:
On 3/22 in revision 158589 the API for Configuration changed in that the return type from getConfigurationClassLoader() changed from ClassLoader to a ConfigurationClassLoader. This means all configurations built before then are now inoperable with the current tree as the attribute type in the persisted GBeanData does not match the new signature.
I can't find any discussion on the list around then that would alert users to this change. It is critical that we let people know when this kind of change is made.
-- Jeremy
