myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] CODI - the future is NOW ?
Date Sat, 05 May 2012 09:36:55 GMT
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 <struberg@yahoo.de>
> To: My Faces Development <dev@myfaces.apache.org>
> 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
> 

Mime
View raw message