Versioning

[alrubinger]

I propose we drop the qualifier (ie. "-Beta7") from all components that are not directly consumed by some other project.

This currently affects everything except jboss-ejb3-as-int and jboss-ejb3-plugin.

Reason: For CR1 I don't want to spend 1/2 a day re-releasing perfectly good projects just to get a name change, and then watch builds to make sure I didn't make a mistake updating all the dependencies. I'll have to repeat this exercise for GA later this week.

Related to this is our versioning scheme in JIRA; I'd like to implement something along the lines of what I'm doing for jboss-aspects, where valid versions are listed per-component. So we'd have:

core-1.0.0
core-1.0.1
build-1.0.0...

This gives a clear indication of which component release a bug fix is actually in. I'm finding it difficult to keep track of questions like: "If fix version is 1.0.0-CR1, what release of Proxy actually contains it? Do I need to re-release Proxy, or has it already been integrated?"

S,
ALR

[wolfc]

Since everything we build is consumed by some other project/component, the proposal is moot. ;-)

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.

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.

As for the version of proxy in 1.0.0-CR1:
$ svn cat http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/tags/jboss-ejb3-as-int-1.0.0-CR1/pom.xml
shows jboss-ejb3-core-1.0.0-CR1
$ svn cat http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/tags/jboss-ejb3-core-1.0.0-CR1/pom.xml
shows jboss-ejb3-proxy-1.0.0-Beta7

We really should be able to do a mvn dependency:tree remotely.

Now the real problem is that Maven is a pain in the ... ehr bottom when it comes to version numbers within artifacts. If only we could specify [latest] in every source pom and the release pom would automatically update itself...

So again it's the tool we use that lets us down.

[alrubinger]

"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:

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

[wolfc]

For Jira we need a single version which signifies the release we do towards AS and Embeddable. So let's add a 'Fix Component Version(s)' and see how that goes. It also will make sure that the roadmap as shown in Jira won't get messy.

[alrubinger]

So there's 2 issues we're discussing:

1) How to model releases in JIRA
2) Are GA dependencies a prereq for a GA release?

Regarding JIRA, we've discussed the following:

* Rename ejb3-as-int to ejb3-project. This defines the components used in a release, and its version becomes the "Release Version".
* Create ejb3-as5-int, ejb3-as6-int outside the scope of projects/ejb3 and under something like projects/ejb3-as-int. These bring in ejb3-project and also add target-specific configs. They are what's brought into AS.
* Add a field for "Fix Component Version" to denote what version of a component has the fix (ie, ejb3-proxy:1.0.0-GA would be a valid value)

I think we're still debating the qualifier issue. Since this morning I hold firm in my previous arguments.

Carlo has brought up that "GA" means "supported". We don't support any community releases (this is for EAP). And we also don't dictate when EAP is released, so there's nothing blocking someone wanting to adopt a Beta-level component into the platform. Once its there, we have to support it.

So I use "GA" to mean "mature" (==stable, feature-complete, tested). And I'm happier applying that label to the whole of EJB3, not to the individual components which comprise it.

S,
ALR

[alrubinger]

An update for anyone following along.

Last week we bumped every component to 1.0.0 as a startoff point for the EJB3 1.0.0 release. We decided to make this one-time concession to line up the release versions to a stable start. In future releases we'll be keeping the cycle independent for components.

S,
ALR