myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject [DISCUSS] CODI - the future is NOW ?
Date Sat, 05 May 2012 09:32:17 GMT
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


Mime
View raw message