5 Replies Latest reply on Jun 13, 2007 6:57 PM by Paul Gier

    Release of jboss-retro

    Paul Gier Master

      I'd like to do a release of jboss retro as soon as we finish up this issue:
      http://jira.jboss.com/jira/browse/JBBUILD-333

      So the release will probably happen at the end of the day today, or sometime tomorrow. I change the version to 1.1.0 since there are a few new features in addition to bug fixes.

      The completion of the maven build is pending an update that I submitted for the maven surefire plugin. So for now, the ant scripts will remain, but the maven build works, it just can't run the 1.4 tests until the updated surefire plugin is released.

        • 1. Re: Release of jboss-retro
          Paul Gier Master

          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.

          • 2. Re: Release of jboss-retro
            David Lloyd Master

             

            "pgier" wrote:
            (...)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.(...)

            So some options are:

            1. Never make changes to runtime class names or method signatures.
            (...)
            2. Change class/package/method names for major versions, and keep a branch for updates to older versions.
            (...)
            3. After moving a class, use inheritance to keep a place holder for the old runtime class.


            What about simply saying that you can't mix versions of retro'd code? If they ran it once, they can do it again... I guess this means I'm in favor of option #2. :-)

            • 3. Re: Release of jboss-retro
              Jason Greene Master

              Another idea would be to have the ability to generate a runtime specific to a package namespace / project namespace as part of the retroing process. So, for example, if you retro'd org.jboss.widget.* you would get a runtime jar that has classes org.jboss.widget.jbossretro.rt.*

              The drawback would be increased sized due to everyone having their own runtime jar, but it isn't that big, and you never have to worry about dependencies, and QA doesn't have to retest yet another combination.

              • 4. Re: Release of jboss-retro
                Paul Gier Master

                Thanks for the suggestions!

                David:
                Option 2 is nice for me because it means I can change whatever I want, but I'm just worried that released products like the app server that use a specific runtime version can be re-retroed because they are already released to our customers. So projects that depend on a particular app server version are stuck with it's retro runtime version, and can't take advantage of new features.

                Jason:
                I think this is a really good idea, and I don't think it would be that hard to implement. I'll have to look into it a little more, but maybe this is the best option for now.

                • 5. Re: Release of jboss-retro
                  Paul Gier Master

                  My plan for now is to reverse the package changes I made and release with the old package structure so I can release tomorrow.

                  For the next release I'll either use Jason's suggestion, or if that ends up not working for some reason, then we'll just go with option 1 or 2.