"wolfc" wrote : Since everything we build is consumed by some other project/component, the proposal is moot. ;-) Aha, I said "directly consumed". :) I stand by the proposal because 1) The JIRA process will closer reflect what we're actually doing 2) Not upgrading stuff for name's sake both saves time and makes for less errors. "wolfc" wrote : Components need a qualifier to make sure that nothing unstable ends up in the supported chain. I want to get to a point were we can say use a version range [1.0,1.1) and not worry about it any more. Qualifiers are doing nothing for us in practice. In actuality, we have the following criteria for any release: * Passes EJB3 Integration TestSuite 100%, except for known issues and transient failures * Passes TCK 100% * No regression in AS TestSuite * Passes module Unit Tests 100% Nowhere along there am I checking that all dependencies are of some particular qualifier. "wolfc" wrote : As for the versioning I agree we need some more transparency there, but we can't create a scheme that's too complicated for users to follow. Since an user doesn't have to find out which component is failing, it'll be reported against our 'global' affected version. Likewise the 'global' fixed version should report the released version. So version per component doesn't sound like a solution to me. Users won't even go that far; they'll report EJB3 problems against their AS version. Or get the version wrong. Either way we'll typically correct "Affects Version" in the JIRA most of the time, same with "component". Regardless of what users are reporting, the problem remains that we currently don't have a scheme in JIRA which correctly models what we're doing. We *do* have version-per-component. To pretend we don't in JIRA is incongruent. One fundamental disagreement we have is that I *do not* believe: anonymous wrote : For any GA release, all dependencies must also be a least GA level I stated our release criteria for ejb3-as-int above. However, a particular component may be implementing some new feature that isn't mature enough to be GA. Take for example: * I start building ejb3-async to fulfill EJB 3.1 requirements of @Asynchronous invocations * At release time, ejb3-async is 1/2 completed. * All the requirements for ejb3-as-int to be released are fulfilled, and we can even preview 1/2 the support of the new ejb3-async module. ejb3-async isn't even complete, so it's not a GA. Does that mean that ejb3-as-int is also not a GA? Why not; it's both more stable and more feature-rich than the previous release. Hmm, so I should promote ejb3-async to GA? But it's not complete. (Start cycle again) That's the philosophical argument. Here's the practical one: I don't want to re-release perfectly good binaries, and update the entire dependency chain, just to get a qualifier promotion that we ignore anyway. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203137#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...