myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gpetra...@apache.org>
Subject Re: [DISCUSS] CODI - the future is NOW ?
Date Sat, 05 May 2012 09:44:26 GMT
imo we should keep the announced plan [1]!

regards,
gerhard

[1] http://s.apache.org/5yV



2012/5/5 Mark Struberg <struberg@yahoo.de>

> 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