[nickarls]

So, if this would have been done earlier, taking the example of the 7.0.0, please correct me where I go wrong:

* On 2011-07-12 7.0.0.Final would have been released as an EAP-Alpha to the community. This one can be used in production for free. There is much rejoycing.

* Development on the source would continue on internal RedHat GIT (or where?)

* People start reporting issues and they get fixed on the internal GIT (or where?)

* By the time of 7.0.1, 135 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

* People download the new EAP an report issues

* By the time of 7.0.2, 79 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

* People download the new EAP an report issues

(insert loop here for various alpha, beta and cr:s)

* By 2012-02-16 1820 issues have been reported and 7.1.0.Final would have been released as an EAP-Alpha to the community. By this time there is already some whining and gnashing of teeth.

As I said, I probably misunderstood somehing about the license, repository location, issue backporting or something so please feel free to correct me.

[henk53]

Rich DiCroce wrote:

What about Maven artifacts for EAP alphas? I notice that a large ZIP file is available on the download page, but are they being published in any public repositories?

Good question. You can find the repo online in unpackaged format here: http://maven.repository.redhat.com/techpreview/eap6/6.1.0.Alpha1/maven-repository

[henk53]

Nicklas Karlsson wrote:

So, if this would have been done earlier, taking the example of the 7.0.0, please correct me where I go wrong:

* On 2011-07-12 7.0.0.Final would have been released as an EAP-Alpha to the community. This one can be used in production for free. There is much rejoycing.

* Development on the source would continue on internal RedHat GIT (or where?)

I have an overwhelming strong feeling that that this GIT repository is hosted on GitHub as well, but just has the private flag set to true.

At least this is what I would do. Cloning the entire repo to some internal private GIT and then later pushing it back, it's possible of course, but if your goal is to hide it from the public you can just as wel set that private flag, can't you?

Nicklas Karlsson wrote:

* By the time of 7.0.1, 135 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

Don't forget the community doesn't just reports but also provides patches, proposals for code diffs and in case of the public version on GitHub pull requests.

Now some clever guy remarked in a related discussion here that the community effort put into this is minimal. That people don't contribute thousands of lines of code (otherwise they would be working for JBoss). In effect, the community likes to cry and whine, but doesn't actually contribute much if anything.

I don't entirely agree with that point.

More often than not, the fix for a very problematic issue that takes weeks and weeks of tracking done is a one-liner. An extra guard somewhere, initializing or tearing down something, etc. Even though most such contributions are indeed between a single and a dozen of lines of code, I don't think it should be underestimated.

[rcd]

Nicklas Karlsson wrote:

So, if this would have been done earlier, taking the example of the 7.0.0, please correct me where I go wrong:

* On 2011-07-12 7.0.0.Final would have been released as an EAP-Alpha to the community. This one can be used in production for free. There is much rejoycing.

* Development on the source would continue on internal RedHat GIT (or where?)

* People start reporting issues and they get fixed on the internal GIT (or where?)

* By the time of 7.0.1, 135 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

* People download the new EAP an report issues

* By the time of 7.0.2, 79 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

* People download the new EAP an report issues

(insert loop here for various alpha, beta and cr:s)

* By 2012-02-16 1820 issues have been reported and 7.1.0.Final would have been released as an EAP-Alpha to the community. By this time there is already some whining and gnashing of teeth.

As I said, I probably misunderstood somehing about the license, repository location, issue backporting or something so please feel free to correct me.

The way I read the new policy, 7.0.1 and 7.0.2 would have been released the same way, since those were AS versions, not EAP versions. The difference is in what would have happened with 7.1.2 and 7.1.3. Those tags were used as the basis for EAP versions, so under the new policy, they would have been released to the community as EAP alphas. I don't work for Red Hat though, so take my analysis with a grain of salt. If you're right and I'm wrong, I agree that would be a huge step backwards, not an improvement.

[rcd]

henk de boer wrote:

Rich DiCroce wrote:

What about Maven artifacts for EAP alphas? I notice that a large ZIP file is available on the download page, but are they being published in any public repositories?

Good question. You can find the repo online in unpackaged format here: http://maven.repository.redhat.com/techpreview/eap6/6.1.0.Alpha1/maven-repository

Thanks, that'll be a big help. I'm not sure why these artifacts aren't being pushed to Central or at least published in the normal public JBoss repository. It seems like they should be, given that the artifacts are all tagged with the AS version and not the EAP version.

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.

[henk53]

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

[rcd]

henk de boer wrote:

Nicklas Karlsson wrote:

* By the time of 7.0.1, 135 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

Don't forget the community doesn't just reports but also provides patches, proposals for code diffs and in case of the public version on GitHub pull requests.

Now some clever guy remarked in a related discussion here that the community effort put into this is minimal. That people don't contribute thousands of lines of code (otherwise they would be working for JBoss). In effect, the community likes to cry and whine, but doesn't actually contribute much if anything.

I don't entirely agree with that point.

More often than not, the fix for a very problematic issue that takes weeks and weeks of tracking done is a one-liner. An extra guard somewhere, initializing or tearing down something, etc. Even though most such contributions are indeed between a single and a dozen of lines of code, I don't think it should be underestimated.

I agree 100%. I've only been using JBoss AS for about a year and a half, and I've reported a number of issues in various projects. When I do, I don't just file a bug report immediately. I spend time trying to understand and isolate the problem. My job is to build and fix bugs in my company's products, not in the tools we use, and I don't have time to get intimately familiar with all of them. But I try to nail down enough details that someone who IS intimately familiar with a particular tool will have an "a-ha!" moment when they read my bug report and will be able to locate and fix the problem easily. A good example is the latest bug I filed: ARQ-1345. It's a relatively minor issue in Arquillian, but I spent some time tracking it down and even delved into the source code to discover that the solution is a one-liner.

There's also the several days I spent figuring out how to make EclipseLink work in AS7 after Hibernate pissed me off one too many times. I wrote some glue code to get it working, attached it to an article I wrote to help anyone else in the community who wanted to use EclipseLink (which a number of people PM'd me about and thanked me for), and signed a contributor agreement at Scott Marlow's request so it could be integrated into the AS codebase. And finally, there's the internal advocacy I've done within my company. We use JBoss AS for a number of different projects, but most of my co-workers don't pay any attention to what's going on in the JBoss world. I sent an e-mail around regarding this new release policy and had to explain several times that EAP alpha == AS final. I'm not sure if it stuck; some people just can't see past that "alpha" label.

Anyways, maybe I'm the exception and not the rule, but contributions definitely flow from the community back to JBoss.

[rcd]

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

I've never heard a thorough explanation of what distinguishes EAP from AS, aside from the obvious benefit of official support. All I can remember having seen are some amorphous statements about more testing, additional patches, and removal of stuff that Red Hat doesn't want to support commercially. I've never seen any concrete examples of what additional testing is done, what things are added, or what things are removed. So my response to the above is: of course people will assume they are the same, because nobody knows what makes them different.

[nickarls]

The way I read the new policy, 7.0.1 and 7.0.2 would have been released the same way, since those were AS versions, not EAP versions. The difference is in what would have happened with 7.1.2 and 7.1.3. Those tags were used as the basis for EAP versions, so under the new policy, they would have been released to the community as EAP alphas. I don't work for Red Hat though, so take my analysis with a grain of salt. If you're right and I'm wrong, I agree that would be a huge step backwards, not an improvement.

I'm referring to

There will be no other community binaries for that major release of the community project after that point because the product builds are effectively a superset and we hope more beneficial to most developers

which is my ultimate source of confusion (what is not released?). Because if that would be true, everyone running a 7.1.1 in production currently would be <censored/> (had it happened earlier).

The big question is "Will a contribution (bug report etc) reported by a non-paying customer be available to him/herself for production use only in a later release compared to a paying customer"

[rcd]

Some official clarification on this would be nice, but here's my two cents. Earlier in that paragraph:

from the point where we start to productise the community project (e.g., AS7.1) we will release all product builds that we create as a result of this process into the community (e.g., EAP 6.0 Alpha 1, which is based on AS 7.1)

As far as I can tell, all EAP versions, even point releases, start out in the community repository. AS 7.1.1 was released to community but also became the basis for EAP 6.0.0, and then later AS 7.1.2 -> EAP 6.0.1 and AS 7.1.3 -> EAP 6.0.2. I'm interpreting the above and the part that you quoted to mean that after a major AS release is productized, there will not be any more AS binaries (which was already the case anyway, but they're now formally making it part of the policy). But there will be EAP binaries, including the EAP alphas that are built from AS tags created after a major AS release is productized. So I think what would have happened under the new policy is:

• AS 7.0.0/7.0.1/7.0.2/7.1.0 are not going to be productized, get released as AS finals.
• AS 7.1.1 is going to be productized, gets released as an EAP alpha. There will be no more releases with the AS label in the 7.x.y line.
• AS 7.1.2 and 7.1.3 are going to be productized, get released as EAP 6.0.1.Alpha and 6.0.2.Alpha.
• AS 7.2.0 is going to be productized, gets released as EAP 6.1.0.Alpha.

This would be consistent with the stance they've had up until now, which is that you can have 7.1.2 and 7.1.3 if you want, because they're tags in a public source repository, but you have to build them yourself. A lot of people, myself included, complained about that policy because it doesn't seem to make much sense. Even the Maven artifacts for 7.1.2/7.1.3 were pushed to Central, so it seems like the only thing that didn't happen was making an AS binary available on the downloads page.

Short version: it looks to me like this new policy is a very verbose way of saying that from now on, all AS final tags will get binary releases, but some of them will be labeled as EAP alphas.

[jason.greene]

Rich DiCroce wrote:

Nicklas Karlsson wrote:

So, if this would have been done earlier, taking the example of the 7.0.0, please correct me where I go wrong:

* On 2011-07-12 7.0.0.Final would have been released as an EAP-Alpha to the community. This one can be used in production for free. There is much rejoycing.

* Development on the source would continue on internal RedHat GIT (or where?)

* People start reporting issues and they get fixed on the internal GIT (or where?)

* By the time of 7.0.1, 135 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

* People download the new EAP an report issues

* By the time of 7.0.2, 79 issues have been fixed and a EAP-version is released (fixing the issues the community reported but can't put into production for free)

* People download the new EAP an report issues

(insert loop here for various alpha, beta and cr:s)

* By 2012-02-16 1820 issues have been reported and 7.1.0.Final would have been released as an EAP-Alpha to the community. By this time there is already some whining and gnashing of teeth.

As I said, I probably misunderstood somehing about the license, repository location, issue backporting or something so please feel free to correct me.

The way I read the new policy, 7.0.1 and 7.0.2 would have been released the same way, since those were AS versions, not EAP versions. The difference is in what would have happened with 7.1.2 and 7.1.3. Those tags were used as the basis for EAP versions, so under the new policy, they would have been released to the community as EAP alphas. I don't work for Red Hat though, so take my analysis with a grain of salt. If you're right and I'm wrong, I agree that would be a huge step backwards, not an improvement.

You are correct. 7.0 was not the basis for EAP but 7.1 was. A simple way to look at the model, is that the most current branch is always community. At some point community moves on to a newer branch, and the older branch potentially becomes EAP only.  Although we aim to have multiple community iterations between EAP so that we can speed up the frequency of releases. If however a branch isn't picked for EAP (EAP majors are purposefully longer, community is more iterative), then it is no longer maintained. Everyone needs to upgrade to the newer community branch. This sort of happened in the past with 7.0, where we moved on to 7.1. At that point things admittedly got confusing, and so we hope the changes to the model will make it easier for everyone to see the differences and benefits between the community and EAP branches.

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)     

[nickarls]

OK, thanks for the info, I think it clears the situation!

Now if you would still consider renaming the  EAP Alpha to "Base", "Foundation", "Bedrock" or something management will love

[marklittle]

"Don't forget the community doesn't just reports but also provides patches, proposals for code diffs and in case of the public version on GitHub pull requests.

Now some clever guy remarked in a related discussion here that the community effort put into this is minimal. That people don't contribute thousands of lines of code (otherwise they would be working for JBoss). In effect, the community likes to cry and whine, but doesn't actually contribute much if anything.

I don't entirely agree with that point."

I'm not exactly sure who this "clever guy" was, but I don't agree with the point either.

[marklittle]

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.

[jason.greene]

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.

The use of 7.2.0.Alpha1-redhat-4 was confusing, and I apologize for that. We should have shipped with the version 7.2.0.Final-redhat-X as the core version, which would have made a lot more sense.  If you compare the sources though you will see that all of the changes in 7.2.0.Final are in EAP 6.1 Alpha. The reason for the confusion has to do with our internal build processes, and the deceision not to tag the 7.2.0.Final release until we had an EAP build that passed all internal review. When we caught it, we were close to releasing and it was decided not to delay the release any further just to update the version info. The Beta will certainly be corrected to point out that it was in fact derived from 7.2.0.Final. We also have indicated this properly in JIRA that EAP 6.1.0.Alpha1 is 7.2.0.Final.