Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=Xt5W1eTevuINTs8B1KNNqKYLVb4wVwwAmu33AUtYUC1t3bm//k+pHoADJl91B3MwxkLPnG1cQAbm3y5tbGl1EtL6yaHOs7ZrPIWpQWhyfpUSYmKdtpt0ykboW8gh3YZSjv1F+jgpKtaJ8J5py78LAVXKrFyhVv3QWOXdNeo1RwA=;
References: <1336210337.64048.YahooMailNeo@web171504.mail.ir2.yahoo.com>
Message-ID: <1336210615.74189.YahooMailNeo@web171504.mail.ir2.yahoo.com>
Date: Sat, 5 May 2012 10:36:55 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: Re: [DISCUSS] CODI - the future is NOW ?
To: MyFaces Development <dev@myfaces.apache.org>,
  Mark Struberg <struberg@yahoo.de>
In-Reply-To: <1336210337.64048.YahooMailNeo@web171504.mail.ir2.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

whoops, figured I did not complete a sentence ;)=0A=0A> g.) if DeltaSpike s=
hips a new feature which replaces a CODI feature, we will =0A... remove thi=
s 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)=0A=0ALieGrue,=0Astrub=0A=0A=0A----- =
Original Message -----=0A> From: Mark Struberg <struberg@yahoo.de>=0A> To: =
My Faces Development <dev@myfaces.apache.org>=0A> Cc: =0A> Sent: Saturday, =
May 5, 2012 11:32 AM=0A> Subject: [DISCUSS] CODI - the future is NOW ?=0A> =
=0A> Hi folks!=0A> =0A> I've recently tried to use CODI and DeltaSpike in t=
he same project and it =0A> didn't work out well.=0A> I think DeltaSpike ha=
s come to a point where we can think about to start the =0A> 'migration pat=
h' from CODI to DeltaSpike, and here is what I've =0A> thought of. The foll=
owing is just a starting point for our discussion and _not_ =0A> yet agreed=
 stuff!=0A> =0A> =0A> =0A> a.) create a new extcdi-2.x branch. Trunk will (=
for now) still remain CODI-only! =0A> We will still ship bug fixes for 1.x =
but all new feature development is done in =0A> DeltaSpike.=0A> =0A> =0A> b=
.) add deltaspike-core-api and deltaspike-core-impl as dependencies to CODI=
=0A> =0A> c.) remove our own ProjectStage stuff. People should use the drop=
-in replacement =0A> from DS instead=0A> =0A> d.) provide a small Extension=
 which rewrites CODI @ProjectStageActivated =0A> annotations to DS @Exclude=
. Of course log a warning that people should change =0A> their impl because=
 they are using a deprecated functionality=0A> =0A> e.) remove all function=
ality from CODI core which got moved to DS. If possible =0A> create a compa=
tible wrapper. Most of the time the effort for end users should =0A> just c=
ontain changing an import package.=0A> =0A> =0A> f.) rewrite all ee modules=
 to make use of the deltaspike-core stuff instead.=0A> =0A> g.) if DeltaSpi=
ke ships a new feature which replaces a CODI feature, we will =0A> =0A> =0A=
> =0A> As explained in a.) we will create a new branch. CODI-2.x is a trans=
ition path =0A> which will end in fully using DeltaSpike at the end of the =
year. For making this =0A> as easy as possible for the end users, we will r=
eally take care about binary =0A> compat and feature changes. Thus I like t=
o propose a strict version schema: =0A> [major nr].[minor nr].[bugfix nr]=
=0A> =0A> =0A> major nr =3D 2 this is fixed to 2 for now.=0A> =0A> minor nr=
 =3D x=A0 whenever we replace a CODI functionality with one from DeltaSpike=
 =0A> we will increment this nr. This indicates that the user might need to=
 change =0A> some import package or do some other small change.=0A> =0A> =
=0A> bugfix nr =3D This is intended for being incremented when we ship a ne=
w COMPATIBLE =0A> version. Means the user can update to the latest without =
having to think about =0A> any compat issues. Of course we will only ship s=
uch bugfix releases in important =0A> cases. If a user has a problem with e=
.g. a 2.1.0 version and doesn't like to =0A> update to a 2.4.0, then he is =
very welcome to ship a patch and we will try to =0A> get a release out of t=
he door. But we will not back-port everyday bugfixes to =0A> all the versio=
ns (that would be a huge amount of work, and no one pays us for =0A> it). =
=0A> =0A> =0A> =0A> This means we will create an own branch for each minor =
nr increment during the =0A> release. Perfectly able to be maintained by th=
e community or downstream users =0A> itself (a local git branch with a rele=
ase to a company internal Archiva or Nexus =0A> is not a big thing nowadays=
).=0A> =0A> =0A> =0A> WDYT?=0A> =0A> =0A> Btw, I really like to thank all t=
he users which are using CODI! I think I can =0A> speak for all committers =
that it was a pleasure to hack this stuff and it's =0A> always nice to hear=
 on conferences that a lot of companies use it (even though =0A> they never=
 speak up on this list or make any public announcement about it).=0A> =0A> =
=0A> LieGrue,=0A> strub=0A>