JBossDeveloper

I don't care very much whether someone trusts my downloads or not. There are 2 issues in 7.1.1.Final which are critical for our team and we had a choice: downgrade to 7.1.0.Final or build 7.1.2.Final from tag. But if someone else wants to download it - why not?

I understand that 7.1.2 was not planned for community, that it is a tag for EAP. But still, now when the tag is there, why not mae a binary release? I cannot understand that no matter from which side I look at it.

Justin Bertram wrote:

 

Every customer is different, but I think it is fair to say that in general customers pay for support.  Of course, support means a lot of different things - everything from a simple ticket on the web portal to extended phone conversations and on-site visits for in-depth analysis or instruction.  People pay for support because it is valuable.  Bits are valuable as well, but as it relates to EAP that's not mainly what Red Hat sells.

Actually, I do agree with that. Just for the record, the company I work for has decided going forward to buy EAP licences again (upgrading from EAP 5), and to the best of my knowledge the availability of AS downloads did not play any role in that decision. Exactly the points you mention are the reason we went with EAP. Some individual departments do use the AS version though, which is sometimes because of the need to be on the cutting edge (Java EE 6 simply wasn't available in EAP last year) and sometimes because of reasons that are a bit hard to explain (complex organization).

Nevertheless, I would understand it if not making the AS 7.1.2 and beyond downloads available was indeed part of a strategy to make the AS series a little bit (only a little bit really) less attractive.

Aliaksei Lahachou wrote:

 

I don't care very much whether someone trusts my downloads or not. There are 2 issues in 7.1.1.Final which are critical for our team and we had a choice: downgrade to 7.1.0.Final or build 7.1.2.Final from tag.

There is also the issue that 7.1.2.Final only seemed to be a tag on which EAP was build. There were obvious more fixes that went into EAP 6.

Is there a clear tag after 7.1.2.Final that corresponds with EAP 6? Say I wanted to build -exactly- EAP 6.0.0. Which tag (if any) would I use for that?

henk de boer wrote:

 

 

Is there a clear tag after 7.1.2.Final that corresponds with EAP 6? Say I wanted to build -exactly- EAP 6.0.0. Which tag (if any) would I use for that?

No there is no tag in the community repository for that, the EAP branch is a different repository.

There is no other tag, but according to this page https://access.redhat.com/knowledge/articles/112673, EAP contains JBoss AS 7.1.2.Final. If they build AS for EAP from other revision, not from tag, that would be completly misleading in my eyes.

In my opinion, the problem here stems from the fact that the tag is called 7.1.2. All other 7.x.y tags up to 7.1.2 were full releases, and I never saw anything indicating 7.1.2 would be any different until the "release date" in JIRA passed, no binaries appeared, and this thread got started. Red Hat/JBoss set a strong precedent and then broke it without warning. If you don't want to make a full release, including binaries, Maven artifacts, etc and just want to make a tag instead, that's fine. But don't call the tag something that implies it's a full release. I get that you want to maintain linkage between the AS versions and the EAP versions, but this system of "sometimes a version is a full release and sometimes it's just a tag" is a very poor and confusing way to accomplish that.

Just my two cents.

Aliaksei Lahachou wrote:

 

There is no other tag, but according to this page https://access.redhat.com/knowledge/articles/112673, EAP contains JBoss AS 7.1.2.Final. If they build AS for EAP from other revision, not from tag, that would be completly misleading in my eyes.

I don't think JBoss/Red Hat is out there to purposedly mislead us. I guess it's simply not in their interest to provide us with AS 7.1.2 releases.

Beta testing for 7.1.x is over. EAP has been released. They will from now on receive bug reports from the EAP users, so in whos interest is it to have us run 7.1.2? Maybe there will be a few extra bug reports from 7.1.2 users, but I guess that is minimal.

Instead, it's in everyone's interest that we (the community) move to the relatively unstable 7.2.x release as soon as the first beta is there, so we can beta test that. A 7.1.2, 7.1.3 etc will only keep us from running that.

I cannot agree with you, henk. I think it is important to get any feedback for EAP to make paying customers happier. 7.1.2.Final, which is the core of EAP, could generate some input from community (in form of bug reports or discussions) which may help making EAP better.

p.s.

Justin Bertram wrote:

 

People pay for support because it is valuable.  Bits are valuable as well, but as it relates to EAP that's not mainly what Red Hat sells.es on download page.

I wonder why the EAP release isn't then simply put on the community download page with a community license.

It's currently already possible to download EAP for free, including the full source code.

Why have the distincion between two locations to download the binary anyway? As far as I can see (correct me if I'm wrong), the main difference is the license. The EAP evalulation download says it's for evaluation purposes only and can not be used for production (but the binary you download for free is identical to the one when you pay), while the for AS it's says it's a community license for which Red Hat does not provide any official support.

If it's all about the support contract, why not unify the downloads?

Aliaksei Lahachou wrote:

 

I cannot agree with you, henk. I think it is important to get any feedback for EAP to make paying customers happier. 7.1.2.Final, which is the core of EAP, could generate some input from community (in form of bug reports or discussions) which may help making EAP better.

I agree with that. Note that the above is not the way I think things should be, but the way I think Red Hat thinks I'm just trying to find an explanation for Red Hat's behavior.

Keep in mind that the AS7 git repo is new compared to the SVN repo used for all the previous versions, and this is the first time an EAP version has needed a tag from it.  Therefore while I can understand that you believed there was a "strong precedent" in place, I don't believe it was as valid as you estimated (if at all).  Furthermore, there are numerous tags in https://svn.jboss.org/repos/jbossas/tags/ which don't have corresponding releases.

Could the tag have been given a more informative name?  Probably so.  Could an announcement been made pro-actively on the forum?  Probably so.  Perhaps these points will be revisited in the future, but I can't say for sure.  What I do know is that a tremendous amount of work has been invested into AS7 in a relatively short amount of time and when resources are stretched sometimes communication isn't 100% ideal.

Community feed-back from AS 7.2.x continues to improve EAP 6 and customer feed-back from EAP 6 continues to improve AS 7.2.x (and beyond).  Just because there's no release of the 7.1.2 tag doesn't mean the improvement cycle stops (in either direction). 

Justin Bertram wrote:

 

Community feed-back from AS 7.2.x continues to improve EAP 6 and customer feed-back from EAP 6 continues to improve AS 7.2.x (and beyond).  Just because there's no release of the 7.1.2 tag doesn't mean the improvement cycle stops (in either direction). 

Thanks for the reply Justin, I love your story!

What about putting up JBoss EAP directly on the main community download page?

Keep in mind that JBoss EAP != JBoss AS.  As the name suggests, EAP (i.e. Enterprise Application Platform) is more than just JBoss AS.  Red Hat packages other components/technologies with JBoss AS in EAP.  Furthermore, there are added profiles with recommended configuration tweaks for specific use cases.  Even if that wasn't the case, there's still good reasons for distinct downloads.  But I digress.

The bottom line is that the community should be able get what it needs (which it can), and paying customers should be able to get what they need (which they can).

See my response below.