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
