[visik7]

This thing that REDHAT doesn't simply says DON'T USE IN PRODUCTION but create FUD around the Jboss User make me mad.

Why they just says you can or cannot use in production environment instead of breaking my balls looking for information around in threads

the question is simple

Can I use 6.1.0 EAP FInal downloadable from https://www.jboss.org/jbossas/downloads in a Production environment?

And the answer should be also simple

YES or NO.

[henk53]

jaikiran pai wrote:

Henk, you do see that this is a 3 page discussion and there are many similar discussions like this one where Red Hat employees have responded and continue to respond to questions, don't you? Please be patient.

It's almost a month now and there's not a single reply on my bullet list. The last questions from other people here were even longer ago.

If there's so much time between questions and a response, it's really hard to say that there's still any communication going on, isn't there? I can understand that sometimes people are busy and it may take a few days, maybe a week or more, but weeks, or months and still no reply is a bit pushing things, isn't it?

[henk53]

Marco Bazzani wrote:

Can I use 6.1.0 EAP FInal downloadable from https://www.jboss.org/jbossas/downloads in a Production environment?

And the answer should be also simple

YES or NO.

I think JBoss will simply say "NO!". and "You have to buy the support contract. End of story."

But it's not that simple. JBoss EAP is and remains open source under the LGPL, which is very specific and was set up with the idea at heart that software should be free. The entire idea of it is that software can be spread and used without restrictions. So saying "you can't use it in production", but at the same time saying "the software is still completely free, has no restrictons (as per the LGPL) and is fully open source" is difficult to understand.

[jason.greene]

henk de boer wrote:

jaikiran pai wrote:

Henk, you do see that this is a 3 page discussion and there are many similar discussions like this one where Red Hat employees have responded and continue to respond to questions, don't you? Please be patient.

It's almost a month now and there's not a single reply on my bullet list. The last questions from other people here were even longer ago.

If there's so much time between questions and a response, it's really hard to say that there's still any communication going on, isn't there? I can understand that sometimes people are busy and it may take a few days, maybe a week or more, but weeks, or months and still no reply is a bit pushing things, isn't it?

Sorry I thought all of your questions were answered. This thread has gotten quite large, and it's hard to differentiate some items as questions, statements or opinions. So how about I just talk a bit about the differences between community and EAP, and also point out some characteristics of our model?

First before you read any further, I ask that everyone reread our existing FAQ:

http://www.jboss.org/jbossas/faq

As you know Red Hat has two middleware offerings. We have a community offering, which is now called "WildFly", and we have a commercial offering called "JBoss EAP (Enterprise Application Platform). The community offering, WildFly, is a traditional open source project that focuses on developing the latest cutting edge middleware technologies. It primarily serves two purposes. One, to give great minds a forum to collaborate, to develop and use technology that interests them. Two, to act as the foundation and launch point for our commerical offering.  WildFly is always moving forward, so once a new major version is released we stop maintaining the older versions.

A number of you have asked if community releases are usable in production, and the answer is a definitive yes! However, the community project is targeted towards enthusiasts, so there is an expectation that you are willing to dig in and "get your hands dirty". If you run into trouble the community will help you, but its a best effort when they have the time, and they will expect you to do a lot of analysis and testing as part of it (i.e. "hey can you give this a try?".). A lot of developers find this to be a rewarding experience (I know I did when I first started using JBoss as an outside user!). However, not everyone has the time or desire.

Our commercial offering has a very different focus. JBoss EAP is a hardened codebase with extensive dedicated QE, including certification against a large number of vendor operating system and database products. It has extremly long maintenance cycles (7-10 years), has world class support with gauranteed SLAs, meets various government certifications, and has a large pool of consulting expertise from Red Hat and partner consultancies. The primary audience is any organization that would rather levage the benefit of a subscription, and focus its talent on its business needs instead of self-supporting a large middleware platform.

Now, one thing I want to point out, which I think would address a lot of the confusion, is that when you "buy" JBoss EAP, either by picking the new zero-cost development subscription or a for pay production subscription, you are not paying for a traditional software license. You are paying for a service (the subcription) and also agreeing to the terms of that service. The new zero-cost developer subscription provides you with access to the same certified JBoss EAP binaries available in our pay plans, along with exclusive content (including a KB, and how-to articles that will grow ove time). You can relate this to something like MSDN. The restriction though is that you must agree to use the subscription for development purposes only. Some have asked what happens if you violate that. The terms clearly state this:

If you use the Red Hat Subscriptions for any other purposes, you are in violation of Red Hat's Enterprise Agreement set forth below and are required to pay the applicable subscription fees, in addition to any and all other remedies available to Red Hat under applicable law.

This development restriction, however, does not apply to EAP alpha releases. EAP alpha releases may be ran in production if you so desire. As to their quality, 6.1.0.Alpha is of equivalent quality to a community final release. However, the Alpha is where the extensive testing and hardening begins, so we recommend GA or later for production if you are interested in using EAP.

Another topic that was touched on is the licensing terms of the software itself. It is correct that the source code of JBoss EAP is licensed under the LGPL and a combination of other OSS licenses. However the distribution also contains our trademarked images and text which we do not allow redistribution without permission. Anyone that wishes to distribute their own derivative of JBoss EAP needs to replace all occurences of Red Hat and JBoss trademarks, and call it something other than JBoss.

Lastly, if you are an ISV or a consulting provider, I would recommend contacting a Red Hat account manager to discuss partnership options, which could potentially offer more flexibility.

Hopefully this reply helps, if you have any further questions please ask, and either I'll reply or I'll hunt down someone that can.

[henk53]

Thanks for the reply Jason, appreciate it.

Jason Greene wrote:

As you know Red Hat has two middleware offerings. We have a community offering, which is now called "WildFly", and we have a commercial offering called "JBoss EAP (Enterprise Application Platform).

That's true, although what I'm seeing in these explanations and in the FAQ is that there's much focus on explaining this commercial difference. If you look at the technical difference, it's really not a totally different product (IMHO). Every EAP release is perhaps 99.9% the same as the AS (now WildFly) release or tag that came before it. The 0.1% difference is in bug fixing ("hardening" as you call it). Now this 0.1% is extremely important of course, as it often seems to be about very pesky little bugs. The fixes are often just one liners or a couple of lines at most (I did extensive diffing between the EAP source and the AS one and this indeed seemed to be the case often).

This really isn't that much different from what most people experience in their coding work. I used to maintain a code base of some 500k LOC. At some point we branched a beta version, and QA would start in that branch. During the course of some 2 to 3 weeks QA would happen and on average some 50 to 100 bugs would be discovered. With every bug fix ammounting to ~5 lines of code on average, we would change ~500 lines of code, which amounts to that same 0.1% again. We would then do a release.

Now is the beta version before we did the QA a totally different product? Of course it isn't. It's 99.9% the same. The difference is some 100 bugs fixed. Even though the difference is small, you wouldn't advise people to use the beta version as the bugs can be very severe (I once accidentally swapped a reward and cost variable, a 6 character difference with HUGE results). With the AS/WildFly releases and the EAP ones it's IMHO exactly like that. AS 7.1.2 in Git was a beta tag, and EAP 6.0.0 was AS 7.1.2 + fixes. AS 7.2 in Git was an alpha tag, and EAP 6.1 was AS 7.2 + fixes.

I think a slightly different way of saying "As you know Red Hat has two middleware offerings" is "The alphas and betas are free, the GA releases are not". It's not entirely unlike Microsoft and Apple making available free downloads of their public betas (with the big difference that JBoss alpha/betas don't "expire").

Jason Greene wrote:

The restriction though is that you must agree to use the subscription for development purposes only.

The way I read this, is that actually the restriction is not there in the first place. The LGPL simply doesn't allow it. But by using the download service of Red Hat/JBoss to obtain the binary build, you agree to this restriction yourself. So it's not that JBoss tells you the fact that something can't be used in production (like e.g. Microsoft tells you you are not allowed to copy Windows), but JBoss asks you to limit yourself that you will not use the software in production, right?

But...

You can't ask users to promise this when downloading the source code (as per the LGPL). So if I just download the source code and run the build script, I get the exact same binaries. But since I have never promissed you anything in that case I can use it in production by running it on an internal server or in whatever way I want.

Now there's the nasty little issue that the build script by default doesn't work. According to Rich it's because the EAP build is "a magnitude more complex", but that seems hardly to be the case (especially considering the code is ~99.9% the same anyway). The main reason the build script doesn't work out of the box is because it has dependencies with slightly different versions than those that are publically available. Some people (see e.g. discussion on Reddit about this) even think it's a conspiracy and that Red Hat/JBoss "sabotages" the build scripts on purpose. I'm not saying this is what I personally think, but it's a somewhat common belief it seems.

Jason Greene wrote:

Anyone that wishes to distribute their own derivative of JBoss EAP needs to replace all occurences of Red Hat and JBoss trademarks, and call it something other than JBoss.

Indeed, since here trademark laws apply, not copyright. Using the software "in production" though doesn't necessitate distribution, so if one just runs JBoss EAP on a private server (even with public access from the Internet) the trademarks don't apply.

In summary, my points from the post from a month ago:

1. JBoss EAP remains open source; LGPL
2. This thread more or less suggests the restriction on production is based on accepting terms when downloading
3. LGPL source code is free to distribute (by definition of the LGPL). Others can build the same binaries without ever accepting any restrictive Red Hat terms
4. LGPL source code is available from the main download page but only after having accepted terms (UPDATE: but this seems is just an oversight, and should be corrected)
5. Exact same LGPL source is also available from Red Hat FTP site without any login or terms to be accepted (ftp://ftp.redhat.com/redhat/jbeap)
6. Other threads suggest or claim the restriction on production is based on the Red Hat trademark (https://community.jboss.org/thread/197780?start=75&tstart=0)
7. Trademark as far as I know comes into effect when distributing a product, but for running in production one does not necessarily have to distribute (can run on your own servers)
8. Self-build from the above mentioned LGPL source allegedly allows you to use the result in whatever way you see fit
9. Self-build is not directly possible; the pom among others references dependencies that have not been published (e.g. Ant 1.8.3-redhat-1 instead of just 1.8.3).
10. The unpublished "hidden" dependencies either seem to have no change in them at all (just a repackaging?) or very little changes. They can be trivially changed into corresponding dependencies that have been published. See https://github.com/hasalex/eap-build
11. A direct self-build probably still has the trademarked term "Red Hat" (or variants) in to it. Yet, in threads about self-build it's (as far as I've seen) not mentioned that this should be removed.
12. If self-build still has the trademarks, but is okay to use in any way fit (update: except distribution), is the legal base for the production restrictions accepting the terms and not the trademarks?
13. What is the exact definition of production usage anyway?

A shortend version:

RedHat/Jboss has three levels of protection to prevent people using JBoss EAP for free in production:

1. When downloading the binary users promise not to use it in production

2. There are trademarks weaved into the code, preventing distribution

3. The build scripts reference dependencies in versions which are not published

Is this correct?

One thing I do would like to add (again) is that I mainly want to get things clear. As Jason explained earlier, if everything had to be free then JBoss could not have become the quality software that it is. We are all engineers and we all have to eat and can't work for free all the time. If you want a 100% free full Java EE implementation then there's Geronimo, but I think that despite IBM's sponsoring even their GA releases don't have the quality that JBoss alpha and beta releases have. For any organization like the ones Jason described above as the primary audience it's of course a total no-brainer to get a subcription, precisely because of the world class support that it gets you.

[ebross]

These people at JBoss take us, the community, for a mug. They think that we only use JBoss for a hobby. We can help them develop and improve their software but not used it in anything serious, like in production.

My project plan needs to be clear from the start, including which AS it will be using in development and production. The new changes in JBoss, WildFly and all that is too confusing and begs the question: what other changes are yet to be revealed. BTW,  I would like to see the download figures since these changes.

Well, after many years of using JBoss, We are now using Apache Geronimo 3.0.1, and I am begining to like it a lot. If at some point we choose to buy the Geronimo support provided by third party or move to IBM, it wouldn't be paintful. At least we know that our objectives will be achieved with fewer unknowns.

[jason.greene]

henk de boer wrote:

Now is the beta version before we did the QA a totally different product? Of course it isn't. It's 99.9% the same. The difference is some 100 bugs fixed. Even though the difference is small, you wouldn't advise people to use the beta version as the bugs can be very severe (I once accidentally swapped a reward and cost variable, a 6 character difference with HUGE results). With the AS/WildFly releases and the EAP ones it's IMHO exactly like that. AS 7.1.2 in Git was a beta tag, and EAP 6.0.0 was AS 7.1.2 + fixes. AS 7.2 in Git was an alpha tag, and EAP 6.1 was AS 7.2 + fixes.

I think a slightly different way of saying "As you know Red Hat has two middleware offerings" is "The alphas and betas are free, the GA releases are not". It's not entirely unlike Microsoft and Apple making available free downloads of their public betas (with the big difference that JBoss alpha/betas don't "expire").

After the split and rename things are actually quite a bit different. WildFly 8 is working on Java EE7 and thus requires JDK7. EAP 6.x on the other hand will remain on Java EE6 and support SDK6. There is some feature sharing though. For example, WildFly 8 and EAP 6.2 are both going to have management role based access control. The big difference is that WildFly focuses on a rapid release cycle (majors releases every 6-9 months with maintenance only on the "current" branch), whereas EAP is on a slow release cycle (roughly 2 years), with a long mainenance (7-10 years for every major) and strict backwards compatibility. Updates to EAP include bug fix releases, security updates, and minor updates that include customer requested features.

It is true that EAP is a derivative of WildFly, but with the vastly different release cycles, only certain releases are chosen as the base, and then there is a divergence from that point. The haderning process off of that initial release usually results in around 500 additional issues or so, although it can vary release to release. I will note however that all of those fixes are always committed back to the latest WildFly release.

From a use perspective that means you can still keep a production app for as long as you like on WildFly. You will however, have to take in larger impacting updates as part of getting the changes and fixes that you need. As an example, you can update from AS7 to WildFly 8, but you might have to adjust your app for EE7 and SE7 changes. EAP saves a lot of the hassle because the updates have low impact.

henk de boer wrote:

Jason Greene wrote:

The restriction though is that you must agree to use the subscription for development purposes only.

The way I read this, is that actually the restriction is not there in the first place. The LGPL simply doesn't allow it. But by using the download service of Red Hat/JBoss to obtain the binary build, you agree to this restriction yourself. So it's not that JBoss tells you the fact that something can't be used in production (like e.g. Microsoft tells you you are not allowed to copy Windows), but JBoss asks you to limit yourself that you will not use the software in production, right?

You are on the right track. It's a contract. To get our certified builds you need a subscription, and to get the subscription you agree that you will not be using those builds for production purposes. If you break that contract there are penalties, but you never lose the ability to use the bits you already obtained, since it's not a software license restriction, but rather a service contract.

henk de boer wrote:

You can't ask users to promise this when downloading the source code (as per the LGPL). So if I just download the source code and run the build script, I get the exact same binaries. But since I have never promissed you anything in that case I can use it in production by running it on an internal server or in whatever way I want.

That's correct. If you build the binaries yourself and run them in production you are not misusing the subscription.

henk de boer wrote:

Now there's the nasty little issue that the build script by default doesn't work. According to Rich it's because the EAP build is "a magnitude more complex", but that seems hardly to be the case (especially considering the code is ~99.9% the same anyway). The main reason the build script doesn't work out of the box is because it has dependencies with slightly different versions than those that are publically available. Some people (see e.g. discussion on Reddit about this) even think it's a conspiracy and that Red Hat/JBoss "sabotages" the build scripts on purpose. I'm not saying this is what I personally think, but it's a somewhat common belief it seems.

I cetainly understand the skepticism but it is extremely complex. Ccertain government certifications (Common Criteria), requires us to rebuild everything in a secured environment. Not just our code, but every runtime and build time dependency (even maven itself and all of its plugins). Various legal requirements from customers require that we sanitize a number of third party aftifacts. Also due to the long term support requirements we have to ensure that all artifacts can be rebuilt in a reproducible manner without using any external internet downloads or repositories. In 7 years projects can actually vanish wihtout a trace. You would also be surprised to learn that a number of third party projects have produced artifacts which do not match their source tag (e.g. some developer forgets to commit a patch against the tag). Lastly all of this has to integrate with the RHEL and Fedora RPM rules and processes. So our internal build system to do all of this is very complex, and its makes alot of assumptions that are specific to our build environment.

Long term though we would like to reduce this complexity, if for no other reason then to make our lives easier.

henk de boer wrote:

Jason Greene wrote:

Anyone that wishes to distribute their own derivative of JBoss EAP needs to replace all occurences of Red Hat and JBoss trademarks, and call it something other than JBoss.

Indeed, since here trademark laws apply, not copyright. Using the software "in production" though doesn't necessitate distribution, so if one just runs JBoss EAP on a private server (even with public access from the Internet) the trademarks don't apply.

The traademark does indeed apply to redistributiuon but as you mention not necessarily to just running the server that you built yourself. I don't blanket say that any public self-use while may are ok because it all depends on what that use is. I recommend reading our trademark guidelines to get a better understading of this:

https://community.jboss.org/wiki/TrademarkGuidelines

http://www.redhat.com/about/companyprofile/trademark/

henk de boer wrote:

1. JBoss EAP remains open source; LGPL
2. This thread more or less suggests the restriction on production is based on accepting terms when downloading
3. LGPL source code is free to distribute (by definition of the LGPL). Others can build the same binaries without ever accepting any restrictive Red Hat terms
4. LGPL source code is available from the main download page but only after having accepted terms (UPDATE: but this seems is just an oversight, and should be corrected)

This was an oversight and should be corrected. The other points are correct.

henk de boer wrote:

1. Exact same LGPL source is also available from Red Hat FTP site without any login or terms to be accepted (ftp://ftp.redhat.com/redhat/jbeap)
2. Other threads suggest or claim the restriction on production is based on the Red Hat trademark (https://community.jboss.org/thread/197780?start=75&tstart=0)

The trademark restrictions only apply to the trademarks themselves and have nothing to do with the "production usage bit", but rather have to do with identifying goods and services. In a nutshell, you can't redistribute our marks, or use them to promote goods or services without permission (see above guidelines). The "production" restriction is from the subcsription agreement.

1. Trademark as far as I know comes into effect when distributing a product, but for running in production one does not necessarily have to distribute (can run on your own servers)

As long as you aren't using the marks, and are simply running an application thats not a problem.

1. Self-build from the above mentioned LGPL source allegedly allows you to use the result in whatever way you see fit

You still have to comply to the terms of the LGPL and honor the restrictions of the trademarks (or remove them), but otherwise you are right.

1. Self-build is not directly possible; the pom among others references dependencies that have not been published (e.g. Ant 1.8.3-redhat-1 instead of just 1.8.3).

The source for the individual thirdparty runtime arifacts are available in our EAP maven repo: (maven.repository.redhat.com). Without having a reproduction of our build environment though you will need to make some alterations to get the build to execute.

henk de boer wrote:

1. The unpublished "hidden" dependencies either seem to have no change in them at all (just a repackaging?) or very little changes. They can be trivially changed into corresponding dependencies that have been published. See https://github.com/hasalex/eap-build

As mentioned above they are in the EAP maven repo. It is true that you can change these to community artifacts, although you might lose a few patches in the process, unless you rebuild those similar to what we do.

henk de boer wrote:

1. A direct self-build probably still has the trademarked term "Red Hat" (or variants) in to it. Yet, in threads about self-build it's (as far as I've seen) not mentioned that this should be removed.

If you intend to redistribute your self-build you need to remove all of our marks.

1. What is the exact definition of production usage anyway?

Are you looking for a legal definition of development use? If so I will have to consult the legal team and relay the exact answer. In general it means creating and testing software. There are some specific example violations in the T&C you can look at as well.

henk de boer wrote:

RedHat/Jboss has three levels of protection to prevent people using JBoss EAP for free in production:

1. When downloading the binary users promise not to use it in production

2. There are trademarks weaved into the code, preventing distribution

3. The build scripts reference dependencies in versions which are not published

Is this correct?

1 and 2 are correct. 3 the sources for the runtime deps are available on maven.repository.redhat.com. There is probably a few build time plugins that aren't published that are needed to do the rebuild-all system, but you can use alternatives for those.

henk de boer wrote:

One thing I do would like to add (again) is that I mainly want to get things clear. As Jason explained earlier, if everything had to be free then JBoss could not have become the quality software that it is. We are all engineers and we all have to eat and can't work for free all the time. If you want a 100% free full Java EE implementation then there's Geronimo, but I think that despite IBM's sponsoring even their GA releases don't have the quality that JBoss alpha and beta releases have. For any organization like the ones Jason described above as the primary audience it's of course a total no-brainer to get a subcription, precisely because of the world class support that it gets you.

I'd like to argue that WildFly is a 100% free full Java EE implementation. In a way its similar to the "old" JBoss model before the split, its just a little faster than the "old" JBoss. Likewise EAP is slower than the old "JBoss".

[jason.greene]

Jason Greene wrote:

henk de boer wrote:

One thing I do would like to add (again) is that I mainly want to get things clear. As Jason explained earlier, if everything had to be free then JBoss could not have become the quality software that it is. We are all engineers and we all have to eat and can't work for free all the time. If you want a 100% free full Java EE implementation then there's Geronimo, but I think that despite IBM's sponsoring even their GA releases don't have the quality that JBoss alpha and beta releases have. For any organization like the ones Jason described above as the primary audience it's of course a total no-brainer to get a subcription, precisely because of the world class support that it gets you.

I'd like to argue that WildFly is a 100% free full Java EE implementation. In a way its similar to the "old" JBoss model before the split, its just a little faster than the "old" JBoss. Likewise EAP is slower than the old "JBoss".

I forgot to mention one comparison point to keep in mind. IBM's model is that Geronimo will always have a very limited feature set in comparison to their proprietary WAS.  Oracle does something similar with Glassfish and Web Logic. In contrast, WildFly always gets all enterprise features that EAP gets, and EAP directly competes with Web Logic and WAS.

[jason.greene]

Benjamin Seyinbour wrote:

These people at JBoss take us, the community, for a mug. They think that we only use JBoss for a hobby. We can help them develop and improve their software but not used it in anything serious, like in production.

That's not true. WildFly, our community release, is intended to be used in production. We have a special separate offering called JBoss EAP, which is oriented towards very long maintenance cycles (7-10) years, strict compatibility, SLAs certification and so on. That you have to pay for, or put the effort into recreating the release. It's pretty much the same as Fedora Linux and RHEL distributions in that regard.

[jason.greene]

{quote}

I'd like to argue that WildFly is a 100% free full Java EE implementation. In a way its similar to the "old" JBoss model before the split, its just a little faster than the "old" JBoss. Likewise EAP is slower than the old "JBoss".{quote}

By community being fast I meant releases faster, and on slow I mean EAP majors have more time between them, with features added in minors between them.

[nickarls]

Thanks Jason for the info. The only issue I'm having is the one with the naming of the final community version (Alpha). I'm familiar with the development process and the name doesn't scare me off but many of the decision makers are not and go into "better safe than sorry"-mode when they see the name. I appreciate that you're a commercial entity that want and need subscriptions but you didn't name the community version "Final" and EAP version "RockSolid", you named the community version "IfItBreaksYouCanKeepThePieces" and the EAP version "ThisWillCoverYourBack" ;-)

[jeffgordon]

Sad that after all these years (been using JBoss for over 10 years) I'll be looking for a new application server.

The total disregard for community members by not fixing bugs (like those in 7.1.1) is shameful and causes a lot of workaround in deployed applications.  We (the community members) provide very visible marketing for JBoss and I have personally been responsible for at least a few companies buying platinum support (because they were deploying to production and wanted a supported product after I left, as a consultant), but if I can't get and use a stable version of JBoss without hiring a lawyer -- then I will use something else.

Aside from the minor rant above, does anyone know if an RHEL license allows use of JBoss EAP?  RHEL comes with JBoss (as I recall) so does that consitute downloading and upgrading to the latest version?

[jason.greene]

Nicklas Karlsson wrote:

Thanks Jason for the info. The only issue I'm having is the one with the naming of the final community version (Alpha). I'm familiar with the development process and the name doesn't scare me off but many of the decision makers are not and go into "better safe than sorry"-mode when they see the name. I appreciate that you're a commercial entity that want and need subscriptions but you didn't name the community version "Final" and EAP version "RockSolid", you named the community version "IfItBreaksYouCanKeepThePieces" and the EAP version "ThisWillCoverYourBack" ;-)

I am not sure if you were thinking we have stopped doing community finals. That is certainly not the case. A big part of this change is that WildFly has a completely independent release schedule. That said, there will be no further 7.x releases because we have moved on to the 8 series. Community will be on WildFly 8, while EAP will continue to add features and fixes to the JBoss EAP 6.x.x series. At some future point a subsequent WildFly major (likely WF 10) will become the base source for an EAP 7.x.x series. A side effect of the timing of this transition is that we essentially repurposed 7.2 as the first EAP minor update (6.1). However, since we had already committed to an AS 7.2 we chose to release the EAP 6.1 Alpha under very flexible terms (run it in production if you like). In addition, we left a source tag around so that if you so desired you could self-build a 7.2.0.Final. This is also the last source-only community release tag.  From that point on, WildFly will only contain release tags that correspond to real releases.

I think the clearest way to present the options is:

1. If you just want a traditional open source project, and don't want to pay for anything, and community support is all you want, pick WildFly
2. If you want long term maintenance (7-10 years) that minimizes the impact when updating, and you want world class support with an SLA, then consider buying JBoss EAP
3. If you want to produce applications for JBoss EAP customers, or you want to easily evaluate a project under EAP, or you just want to familiarize yourself with EAP, then pick our zero-cost development subscription.

[henk53]

Jason, thanks a lot for the very complete explanation. I think that everything for the first time is now crystal clear for me

Maybe not everyone agrees with how JBoss does things, or maybe they do, but despite of what people think it should at least now be totally clear for everyone.

Jason Greene wrote:

After the split and rename things are actually quite a bit different. WildFly 8 is working on Java EE7 and thus requires JDK7. EAP 6.x on the other hand will remain on Java EE6 and support SDK6.

Of course, but that still doesn't make it a completely different thing. In this case WildFly 8 will be the first "early alpha" (just making up a name here) of a major new version of the server. Eventually this early alpha will become an alpha (say 8.0.1 or so) which will turn into a beta (say 8.1) and then eventually you'll get to a GA (say 8.1.2 or 8.2). This GA will then be called EAP.

At the same time you'll be creating patches for 7.x (which you call EAP too then).

IMHO again it's not that much different with the LTS releases that Canonical does for Ubuntu. A specific release (e.g. 12.04) will receive a much longer support and gets the LTS tag. Canonical calls every release simply "Ubuntu" and hasn't invented a new name, it just adds a tag.

What I personally think would me much more clear and closer to reality is if you just named versions continously. E.g.

E.g.

JBoss 6.0

JBoss 6.1

JBoss 7.0

JBoss 7.1

JBoss 7.1.1

JBoss 7.1.2 EAP

JBoss 7.1.3 EAP

JBoss 7.2 EAP

JBoss 8.0

JBoss 8.0.1

JBoss 8.1

JBoss 8.1.1

JBoss 8.1.2 EAP

etc

With such a scheme it would be immediately clear what place each EAP release has in the grand scheme of things. I have to admit that by simply placing EAP with its release date on the main download page has already made this 100x more clear than before, so you already did an amazing job there, but still I think having a unified version numbering would make it even clearer.

If I look at the source of JBoss, the tagging and the startup log lines I get the impression that the various JBoss developers internally already follow that naming scheme anyway. But this is perhaps a bit of a different discussion

Again, thanks a bunch for the clarification!

[jason.greene]

henk de boer wrote:

Jason, thanks a lot for the very complete explanation. I think that everything for the first time is now crystal clear for me

Maybe not everyone agrees with how JBoss does things, or maybe they do, but despite of what people think it should at least now be totally clear for everyone.

Thanks for baring with me.

henk de boer wrote:

Jason, thanks a lot for the very complete explanation. I think that everything for the first time is now crystal clear for me

Maybe not everyone agrees with how JBoss does things, or maybe they do, but despite of what people think it should at least now be totally clear for everyone.

Jason Greene wrote:

After the split and rename things are actually quite a bit different. WildFly 8 is working on Java EE7 and thus requires JDK7. EAP 6.x on the other hand will remain on Java EE6 and support SDK6.

Of course, but that still doesn't make it a completely different thing. In this case WildFly 8 will be the first "early alpha" (just making up a name here) of a major new version of the server. Eventually this early alpha will become an alpha (say 8.0.1 or so) which will turn into a beta (say 8.1) and then eventually you'll get to a GA (say 8.1.2 or 8.2). This GA will then be called EAP.

At the same time you'll be creating patches for 7.x (which you call EAP too then).

IMHO again it's not that much different with the LTS releases that Canonical does for Ubuntu. A specific release (e.g. 12.04) will receive a much longer support and gets the LTS tag. Canonical calls every release simply "Ubuntu" and hasn't invented a new name, it just adds a tag.

What I personally think would me much more clear and closer to reality is if you just named versions continously. E.g.

E.g.

JBoss 6.0

JBoss 6.1

JBoss 7.0

JBoss 7.1

JBoss 7.1.1

JBoss 7.1.2 EAP

JBoss 7.1.3 EAP

JBoss 7.2 EAP

JBoss 8.0

JBoss 8.0.1

JBoss 8.1

JBoss 8.1.1

JBoss 8.1.2 EAP

etc

With such a scheme it would be immediately clear what place each EAP release has in the grand scheme of things. I have to admit that by simply placing EAP with its release date on the main download page has already made this 100x more clear than before, so you already did an amazing job there, but still I think having a unified version numbering would make it even clearer.

If I look at the source of JBoss, the tagging and the startup log lines I get the impression that the various JBoss developers internally already follow that naming scheme anyway. But this is perhaps a bit of a different discussion

Again, thanks a bunch for the clarification!

Yes we do report an internal core version for exactly that purpose (the bit in parens). The main idea was so that when someone chose to migrate from WildFly to JBoss EAP they would have an estimation of what is already there and what might be coming.

So I take your point that its not completely different software. A specialized fork is probably a more accurate description. What I was getting at is that the planning and scheduling is different. I don't know alot about Ubuntu's LTS release program; however, their description indicates that LTS has no additional features added? The model for WildFly & EAP is essentially the same as RHEL and Fedora:

https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux?rd=RHEL#History

Right now RHEL is on 6.4, and was originally based on Fedora 13 (RHEL 6.0). Fedora is currently on 19, and RHEL 7 is likely to be based on that, but will diverge just as RHEL 6.1 - 6.4 did.

The name change was a tough decision, but we felt it was ultimately the best way to address a great deal of confusion around the differences between JBoss EAP and JBoss AS. I don't doubt it will take some time for everyone to get used to it though.