+1 for b) as well. I assume we might want to start on 1.1 work before the spec is final, so might not want to wait that long for a branch to do that work.
Sincerely, Joe On Wed, Oct 5, 2011 at 5:35 AM, Gerhard Petracek <[email protected]> wrote: > +1 for b) as soon as cdi 1.1 is final > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2011/10/5 Mark Struberg <[email protected]> > >> Hi folks! >> >> While working on OWB-589 yesterday, I realized that we cannot use our old >> 1.0 TCK for new CDI-1.1 features anymore. >> While OWB always was more like a CDI-1.1 container than 1.0 ('global' >> interceptors, no BDA), there are still some changes which are notable. >> >> *) CDI-1.1 adds a few annotations, so firstly we need to add those to a new >> geronimo-specs-jcdi-1.1. Dblevins, Djencks, how do we do this best? Should I >> just ship patches? >> *) The CDI-1.1 TCK is now based on arquillian -> we have to change our tck >> integration >> *) we can finally remove all the BDA handling stuff with the public static >> ThreadLocals (at least a few of them). This got removed from the spec >> >> >> From a users perspective CDI-1.1 is pretty much backward compatible. From >> the TCK perspective, CDI-1.1 removed some unnecessary restrictions, e.g in >> the Serialization check area. >> >> How do we continue with our release planing? >> >> There are a few possible options: >> >> a.) 1.1.2-SNAPSHOT (as all versions since 1.0.0-alpha1) already contains a >> few CDI-1.1 parts, so should we just continue? >> >> b.) Since Geronimo, TomEE and WebSphere use OWB as CDI-1.0 container, >> should we now release a 1.1.2 version and create a maintenance branch for >> it? This would mean that the 1.1.x branch would not get much love from us >> anymore, and we will focus on 1.2.0-SNAPSHOT >> >> c.) Should we just branch 1.1.x now (without a release) and move our trunk >> to version 1.2.0-SNAPSHOT, then actively maintain both? (That would mean >> that someone else than I must handle the maintenance branch). >> >> LieGrue, >> strub >> >
