[cdi-dev] general goal for CDI-1.1

[Pete Muir]

On 11 May 2011, at 16:49, Pete Muir wrote:

> Hi Mark,
> 
> On 11 May 2011, at 15:18, Mark Struberg wrote:
> 
>> Hi folks!
>> 
>> I've seen lots of different ideas in the CDI issue tracker. 
>> 95% of those ideas are really great.
> 
> Absolutely. And regardless of whether a feature/change makes it into this current revision or is postponed, we should keep having these discussions.
> 
>> Some of them are easy little corrections/clarifications, others are pretty huge changes/extensions to the fundamental CDI mechanics.
> 
> I know you are aware of this, but I do want to reiterate we cannot make non-backward compatible changes to 1.0.
> 
>> 
>> So please let me ask you what the goal of CDI-1.1 is?
> 
> The goal of 1.1 is to address a number of shortcomings identified by the community. It is not a goal to add any headline new features. As a rule of thumb, we should not be looking at adding any new chapters to the specification. We should think hard before adding any sections to chapters. We will probably need to add sub sections to chapters. IOW we shouldn't be adding any new headline features, but we can certainly enhance an existing feature. Let's take a couple of examples that have cropped up so far. By these guidelines we shouldn't be considering adding something like XML configuration, as that would be an entirely new area of the spec. OTOH observer ordering is certainly something we could consider as it enhances an existing feature (the resolution of observers).
> 
> As CDI is a key part of Java EE, we are also aligning with the updates to specs in EE7, and also pursuing the overall goal of multi-tennancy.
> 
> You can find the items committed to in the JSR proposal which was approved by the JCP EC. I would expect most of these items to be addressed, and AIUI these represent the majority of issues identified to date by the community. We also put in a line about addressing any new issues (or issues that had not previously been communicated) in order to keep the door open for the future.
> 
> So to recap, the overall goal is refinement of existing features.
> 
>> 
>> Are we preparing for a quick MR or is it a rather a full scale next version?
> 
> This is not an MR but a full JSR. In JCP terms and MR is conducted solely by the spec lead and does not require formation of an EG. 
> 
> In typical software release taxonomy you would equate this to a minor version (whilst a MR would typically be a micro version).
> 
>> And what's the proposed time scale?
> 
> Aligned with EE7, you can find this on the JSR and repeated here:
> 
> March 2011	Expert group formed
> Q3 2011	Early Draft Review
> Q1 2012	Public Review
> Q3 2012	Final release.

For those of us not versed in JCP terminology, this means we have around 9 months in which to spec out in moderate detail the changes we want to see. The 6 months after that should focus on implementation by the RI, TCK development, and handling anything that comes out of this. Red Hat are intending to develop the RI and TCK alongside the spec (more on this soon, just sorting out the resourcing for it).