-
1. Understanding the JBoss release cycle
jaikiran Jan 12, 2011 8:17 AM (in response to gibsonc)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 Jan 12, 2011 8:37 AM (in response to gibsonc)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 Jan 12, 2011 9:52 AM (in response to gibsonc)You can follow the JBoss AS 6.0.1 Executive Summary for status on the release.
-
4. Understanding the JBoss release cycle
peterj Jan 12, 2011 10:20 AM (in response to gibsonc)@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 Jan 13, 2011 2:10 AM (in response to 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 Jan 13, 2011 2:29 AM (in response to gibsonc)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.