-
30. Re: On the new AS/EAP merger
jason.greene Mar 13, 2013 4:24 PM (in response to marklittle)Mark Little wrote:
henk de boer wrote:
Rich DiCroce wrote:
Speaking of which, does Red Hat have any plans to better align the versioning at some point? Because we now have EAP 6.1.0.Alpha1 is the same as AS 7.2.0.Final, and then the Maven artifacts have version 7.2.0.Alpha1-redhat-4. This is going to get very confusing, very quickly.
Yes, I fully agree and many other developers and clients I speak to pretty much tell me the same thing.
It doesn't looks like JBoss/RedHat want to align the version numbering any time soon. They seemingly are afraid of the assumption that community and product releases are identical. See e.g. https://community.jboss.org/blogs/mark.little/2012/10/06/jbossas-renaming
If you read and understood the article you linked to then you would see that it's nothing to do with being afraid, but removing confusion that exists.
I'll add to that and say that the big reason that EAP 6+ reports two version numbers is precisely to show the association. It's in our interest for our customers (and potential customers) to know where the code comes from, so they know how to handle a migration from community to EAP.
-
31. Re: On the new AS/EAP merger
rodakr Mar 13, 2013 5:06 PM (in response to jason.greene)community FINAL == EAP Alpha.
Depends what sombody understand under "production", but if you guys are work for a company, which whant to run an Application in Production with real customer, you better wait for EAP Final!
Once your application is in production, usually you can't just wait until next major community Major version... if you habe bugs, and you can be shure, you will allways have!
If you still don't belive, take a look how much patches you will find for EAP 6.0.0 and what they are good for...
Second think... you will be surprise how much thinks you found in Forum, which doesn't work or are not supported... you will get fixed using paid support.
Third.. if you are on project, where you have limited time for your application, you don't want spend time on App Server issues...
....
:-)
-
32. Re: On the new AS/EAP merger
dlmarion Mar 13, 2013 6:57 PM (in response to jason.greene)It probably helps to look at a theoretical roadmap that I posted in another thread:
Community Parallel: 7.0.x -> 7.1.x -> (7.2) -> Community 8 releases -> Community 9 releases -> Community 10 releases -> Community 11 releases
JBoss EAP6 Parallel: ^ EAP 6.1 Alpha -> 6.1.x releases -> EAP 6.2 Alpha -> EAP 6.x release stream continues (up to 10 years depending on contract etc)
JBoss EAP7 Parallel ^ EAP 7.0 Alpha (Perhaps based from 9 Final) -> EAP 7.x release stream (up to 10 yrs)
I will say that I am a little confused about future patches on the 7.2.0 line. I understand that
1. EAP 6.1 Alpha is equivalent to 7.2.0.Final (available today and can be deployed in production at no price)
2. EAP 6.1 Beta will be available to developers for zero-fee (need subscription to deploy in production)
3. EAP 6.1 Final will be available paid subscription
Will there be a 7.2.x? If not in binary form, will there be one in source form that can be built and used in production for free (with no support obviously)?
I understand what is really happening here, but I'm trying to give my customer an idea of the new process so that they can decide what direction they want to go. I will also say that changing the distribution name of the "alpha" to something like "foundation" would be greatly appreciated as my customer doesn't trust it on their network even though I explained this change.
-
33. Re: On the new AS/EAP merger
jason.greene Mar 13, 2013 7:02 PM (in response to dlmarion)Dave Marion wrote:
I will say that I am a little confused about future patches on the 7.2.0 line. I understand that
1. EAP 6.1 Alpha is equivalent to 7.2.0.Final (available today and can be deployed in production at no price)
2. EAP 6.1 Beta will be available to developers for zero-fee (need subscription to deploy in production)
3. EAP 6.1 Final will be available paid subscription
All releases of EAP (including GA) are available via the zero-fee dev subscription
Dave Marion wrote:
Will there be a 7.2.x? If not in binary form, will there be one in source form that can be built and used in production for free (with no support obviously)?
No there will be no more releases of any version of 7.x, community is now on 8. The 7.x line is now EAP 6.x, and so patches are all there.
-
34. Re: On the new AS/EAP merger
dlmarion Mar 13, 2013 7:14 PM (in response to jason.greene)Jason,
Thanks for the quick response. I'm not familiar with the pricing structure, is there a link that explains what the zero-fee dev subscription gives me? I found http://www.redhat.com/about/subscription/ but I couldn't find an answer within a few minutes. I'm assuming that it doesn't allow us to deploy the EAP beta, GA, and patch releases in production for free, and if that is true, then what this means is that the free version of the app server ends when RedHat/JBoss decides to turn it into a product. Do I have that correct?
Dave
-
35. Re: On the new AS/EAP merger
dlmarion Mar 13, 2013 7:30 PM (in response to dlmarion)I think I found the subscription guide: http://www.redhat.com/f/pdf/JBossSubscriptionGuide.pdf. Any thoughts on renaming the EAP 6.1 download? It's been mentioned several times in this thread.
-
36. Re: On the new AS/EAP merger
pmuir Mar 14, 2013 6:26 AM (in response to rcd)We are looking to see if we can push the artifacts for EAP to maven central, but this isn't high priority, so I wouldn't expect this for EAP 6.1.
-
37. Re: On the new AS/EAP merger
pmuir Mar 14, 2013 6:29 AM (in response to dlmarion)We will be updating the info on jboss.org with more info on the restrictions of the $0 subscription over the next few weeks, but Mark's blog is a good explanation, in non-legal terms ;-) As long as you agree to $0 subscription terms and condtions, the EAP 6.1 subscription onward, including GA, is free to use for development. With this you get access to binaries and forum based support.
I don't believe the EAP download build categorization will be altered (Alpha, Beta, CR, GA) - this is an industry standard naming scheme, and to change it would only introduce more confusion IMO.
-
38. Re: On the new AS/EAP merger
richsharples Mar 14, 2013 8:14 AM (in response to pmuir)To add to what Pete said. It's called ALPHA precisely because we do not believe it's suitable for production use - changing the name to something else will not change that. We do believe the ALPHA is good enough for evaluating new features and bug fixes and for development use (prior to the General Availability of EAP 6.1). Of course you are free to use the ALPHA how you want but it would be irresponsible of us if we didn't provide some guidance.
The proces of taking upstream releases and "hardening" them for production-use is a long one and involves a huge amount of additional testing (performance, security, regression, stress), certification (different JVMs, DB, etc.). I covered the process in some detail on my blog a few years ago : http://blog.softwhere.org/archives/1035 (a little dated but still useful).
Hope this helps.
Rich Sharples
Red Hat
-
39. Re: On the new AS/EAP merger
nickarls Mar 14, 2013 8:57 AM (in response to richsharples)"Alpha - currently running thousands of production system just on sheer luck"
-
40. Re: On the new AS/EAP merger
dlmarion Mar 14, 2013 10:17 AM (in response to nickarls)Nicklas Karlsson wrote:
"Alpha - currently running thousands of production system just on sheer luck"
Exactly. I'll bet the community edition has never been "production ready", but people have been doing it for years.
-
41. Re: On the new AS/EAP merger
jason.greene Mar 14, 2013 11:13 AM (in response to dlmarion)Dave Marion wrote:
Nicklas Karlsson wrote:
"Alpha - currently running thousands of production system just on sheer luck"
Exactly. I'll bet the community edition has never been "production ready", but people have been doing it for years.
You guys have a good point. It's all relative right? EAP is way more conservative, so just to make it to Alpha, the software has to be good. However there is a real difference between EAP GA and Alpha, and we feel the version names represent that difference.
I do, however, understand your position. I have worked in places that even refused to run anything called .0 (GA/Final or not). Pushing the community to be faster than EAP should help with this issue, because you can then you will have the option of using the latest EAP (Alpha or otherwise) or the latest community release on the latest community major.
In the meantime we did leave a 7.2.0.Final community tag, so if you prefer you can just build that yourself, and it will not identify itself EAP 6.1.0.Alpha. However as I mentioned, earlier the next community release is going to be 8.0.0.Alpha1, and we hope to move to final very quickly. While there will be future EAP 6.x Alphas, they are all based on the EAP branches.
Someone earlier said they didn't understand the difference, and what the value in EAP is, other than support. We feel the biggest value of the subscription, outside of amazing support, is a very long running maintenance stream (up to 10 years) on a hardened branch. So the choice we offer is between being on the bleeding edge, and getting the latest features, and always updating everything for them, or a subscription based on a series of stable conservative branches. Part of making the EAP subscription freely available for development is to give a taste of that and to bypass the evaluation hurdle we had in the past.
-
42. Re: On the new AS/EAP merger
nickarls Mar 15, 2013 2:14 AM (in response to jason.greene)True. But you must confess that it's not entirely unbeneficial for the EAP that the community releases have been "downgraded" (in the naming-sense we discussed) from Final to Alpha?
-
43. Re: On the new AS/EAP merger
nickarls Mar 28, 2013 4:23 AM (in response to nickarls)OK, so I reported to JRebel that I had some classloading issues. This was the response
EAP 6.1.0.Alpha1 is quite new and, well, it is alpha. We haven't tested JRebel with it yet. But thanks for letting us know. We shall try it when we have time. We usually don't put too much effort in supporting milestone versions since they tend to change pretty quickly
*facepalm*
Could. We. Please. Rename. The. Community. Version?