[jboss-dev-forums] [Design of JBoss Build System] - Re: Release of jboss-retro

[pgier]

Kabir brought up the issue of backwards compatibility with the previous versions of retro, so I'm putting off the release until we figure out a good plan.

The problem is that in the new version of jboss retro, some of the classes have been moved to new packages.  So code that was retroed with the previous version of jboss-retro will not work with the new runtime.  This means that if aop is retroed with the new version it depends on the new runtime, and if the app server is retroed with the old version, it will depend on the old runtime.

So some options are:

1.  Never make changes to runtime class names or method signatures.
Pro: This will allow backwards compatibility in most cases.
Con: Not much flexibility for refactoring, we will probably have to include some automated way to run tests that are retroed with the old version running on the runtime of the new version.

2.  Change class/package/method names for major versions, and keep a branch for updates to older versions.  In this case we will keep a branch to add new features to an old version but keep a compatible runtime.
Major versions would be allowed to break compatibility.
Pro:  Allows refactoring
Con: Would have to maintain multiple branches.

3.  After moving a class, use inheritance to keep a place holder for the old runtime class.
This would mean that after a class is moved, a new subclass of the new class is created in the old location.
Pro: Allows refactoring and backwards compatibility
Con: Causes a lot of extra placeholder classes hanging around.

Maybe the best option is to stick with option 1, until we are able to have multiple retro-runtimes loaded at once (osgi classloader).  But I would appreciate any feedback on this.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054126#4054126

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054126