6 Replies Latest reply on Jan 13, 2011 2:29 AM by nickarls

    Understanding the JBoss release cycle

    gibsonc

      Hi all

       

      I have converted our entire infrastructure from Glassfish 2.1 to Jboss - currently running successfully on 5.1.0GA. Of course there is one major hurdle and that is centralised management with RHQ and 5.1.0 which doesn't work and will not be fixed.

       

      From what I can gather 5.1.0 is the last 5 release. Thereafter all the effort went into JBoss 6. Now that 6 is released, I started testing with it and the management integration works well with a few small bugs I have picked up so far.

      What I would like to understand is what happens to the 6 release. Is it now 'abandoned' and all work starts on version 7?

      Given the presentation at Jboss world, this seems to be the case, since 7 becomes EAP6.

       

      Are any fixes backported to lets say a 6.1 release? At what point can one consider a release stable enough for production use, since if there are no fixes and you need to wait till the next major release which could only be a year later which may introduce its own set of new issues.

       

      The reason I ask is that there were numerous releases under version 4, but now it seems all the projects are rushing ahead at breakneck speed with no clear plan to get a stable, bullet proof release.

       

      I must be missing something

       

      Regards

      Craig

        • 1. Understanding the JBoss release cycle
          jaikiran

          gibsonc wrote:

           


          What I would like to understand is what happens to the 6 release. Is it now 'abandoned' and all work starts on version 7?

           

           

          Are any fixes backported to lets say a 6.1 release?

          The JBAS JIRA roadmap shows a 6.0.1 bug fix release. So it's not abandoned.

          • 2. Understanding the JBoss release cycle
            dimitris

            It's all here: http://www.jboss.com/products/community-enterprise/

             

            In sort, the release model after the Red Hat aquisition and the move to the JBossAS/EAP model (a la Fedora/RHEL), is that the community releases (JBossAS) give emphasis to new features and innovation while the productized releases (EAP) ephasise on stability and long term support.

             

            Bug fixing releases, like we did in the past with 5.0.1 or even 5.1.0 (with some new features) are possible, but in general, after a productized release is forked off of a version of the community project, bug fixing will continue on the supported product for that particular release train.

             

            Of course, bug fixing always takes place at the current project 'trunk', but this is coupled with new features (and new bugs obviously). For peace of mind, you can switch to the supported product EAP and get all the benefits of a support subscription. Or if you stick with the community project you can always work with the community to backport a fix and patch your particular instance. It's a choice you have to make.

             

            So, back to the current situation, a bug fixing 6.0.1 is possible to iron out any initial bugs/glitches/annoyances, although the focus now moves to AS7.

             

            Hope that helps!

            • 3. Understanding the JBoss release cycle
              shelly.mcgowan

              You can follow the JBoss AS 6.0.1 Executive Summary for status on the release.

              • 4. Understanding the JBoss release cycle
                peterj

                @gibsonc, based on your comments, I would think that you would ignore AS and instead be concerned with EAP since EAP already does what you want (patches, full support, stability, etc.)

                • 5. Understanding the JBoss release cycle
                  gibsonc

                  Hi all

                   

                  Thanks for the replies, they have answered my question perfectly.

                   

                  Peter, you are correct - EAP is right for us, but in a corporate as large as ours, the procurement process is slow as molasses and we needed a quick solution and thats where the frustration began - trying to get it all working resorting to endless forum trawling. We will deploy EAP in due course.

                  Ironically, when I met with the Redhat sales team, they were well aware of this mess in the community where nothing seems to integrate properly - its a common thread so at least I know I am not alone in my frustrations.

                   

                  The other side of the argument though, is that this then seems to indicate that one shouldn't even bother to deploy community releases, even into the test environment which is contrary to why you have a community release in the first place, because should you find any issues and report them or even fix them, you going to wait a long time before you see those issues resolved in a proper release and even longer depending where you are in the release cycle to get an EAP release based on this code, but I see this is at least partially addressed by the bugfix release 6.0.1 in planning.

                   

                  Kind Regards

                  Craig

                  • 6. Understanding the JBoss release cycle
                    nickarls

                    It does answer the question I was wondering about a few monthts ago, the "why are so many top resources thrown at AS 7 when AS 6 isn't out yet?" The release announcements for AS 6 was a bit toned down also, being mostly on own sites and blogs.

                     

                    But since most components going into AS 6 and AS 7 are common, in best cases backporting bugfixes to modules could be just dropping in a new jar.