imo we should keep the announced plan [1]! regards, gerhard
[1] http://s.apache.org/5yV 2012/5/5 Mark Struberg <[email protected]> > whoops, figured I did not complete a sentence ;) > > > g.) if DeltaSpike ships a new feature which replaces a CODI feature, we > will > ... remove this feature from COD-2.x.y, provide a compat layer and > increment the minor nr to x+1 (2.0.1, +new feature -> 2.1.0) > > LieGrue, > strub > > > ----- Original Message ----- > > From: Mark Struberg <[email protected]> > > To: My Faces Development <[email protected]> > > Cc: > > Sent: Saturday, May 5, 2012 11:32 AM > > Subject: [DISCUSS] CODI - the future is NOW ? > > > > Hi folks! > > > > I've recently tried to use CODI and DeltaSpike in the same project and it > > didn't work out well. > > I think DeltaSpike has come to a point where we can think about to start > the > > 'migration path' from CODI to DeltaSpike, and here is what I've > > thought of. The following is just a starting point for our discussion > and _not_ > > yet agreed stuff! > > > > > > > > a.) create a new extcdi-2.x branch. Trunk will (for now) still remain > CODI-only! > > We will still ship bug fixes for 1.x but all new feature development is > done in > > DeltaSpike. > > > > > > b.) add deltaspike-core-api and deltaspike-core-impl as dependencies to > CODI > > > > c.) remove our own ProjectStage stuff. People should use the drop-in > replacement > > from DS instead > > > > d.) provide a small Extension which rewrites CODI @ProjectStageActivated > > annotations to DS @Exclude. Of course log a warning that people should > change > > their impl because they are using a deprecated functionality > > > > e.) remove all functionality from CODI core which got moved to DS. If > possible > > create a compatible wrapper. Most of the time the effort for end users > should > > just contain changing an import package. > > > > > > f.) rewrite all ee modules to make use of the deltaspike-core stuff > instead. > > > > g.) if DeltaSpike ships a new feature which replaces a CODI feature, we > will > > > > > > > > As explained in a.) we will create a new branch. CODI-2.x is a > transition path > > which will end in fully using DeltaSpike at the end of the year. For > making this > > as easy as possible for the end users, we will really take care about > binary > > compat and feature changes. Thus I like to propose a strict version > schema: > > [major nr].[minor nr].[bugfix nr] > > > > > > major nr = 2 this is fixed to 2 for now. > > > > minor nr = x whenever we replace a CODI functionality with one from > DeltaSpike > > we will increment this nr. This indicates that the user might need to > change > > some import package or do some other small change. > > > > > > bugfix nr = This is intended for being incremented when we ship a new > COMPATIBLE > > version. Means the user can update to the latest without having to think > about > > any compat issues. Of course we will only ship such bugfix releases in > important > > cases. If a user has a problem with e.g. a 2.1.0 version and doesn't > like to > > update to a 2.4.0, then he is very welcome to ship a patch and we will > try to > > get a release out of the door. But we will not back-port everyday > bugfixes to > > all the versions (that would be a huge amount of work, and no one pays > us for > > it). > > > > > > > > This means we will create an own branch for each minor nr increment > during the > > release. Perfectly able to be maintained by the community or downstream > users > > itself (a local git branch with a release to a company internal Archiva > or Nexus > > is not a big thing nowadays). > > > > > > > > WDYT? > > > > > > Btw, I really like to thank all the users which are using CODI! I think > I can > > speak for all committers that it was a pleasure to hack this stuff and > it's > > always nice to hear on conferences that a lot of companies use it (even > though > > they never speak up on this list or make any public announcement about > it). > > > > > > LieGrue, > > strub > > >
