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 >
