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:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=S0mdhUaB9THJHAmLMc/excWLIwd/bsSUqzV0pejEFmLJNi0v068xIMt5t9KDIaxZNpwsqDuF3EDDWvw0iZUkfbYu+5jwPIETmzrv0sSpFF1y+ek6Fkc9kGRJrcyufqHRvgCly/nsw9JiSIlIKB5w1QQrzz1HsUqGixkFaxdF1aU=;
Message-ID: <1336210337.64048.YahooMailNeo@web171504.mail.ir2.yahoo.com>
Date: Sat, 5 May 2012 10:32:17 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: [DISCUSS] CODI - the future is NOW ?
To: My Faces Development <dev@myfaces.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi folks!=0A=0AI've recently tried to use CODI and DeltaSpike in the same p=
roject and it didn't work out well.=0AI think DeltaSpike has come to a poin=
t where we can think about to start the 'migration path' from CODI to Delta=
Spike, and here is what I've thought of. The following is just a starting p=
oint for our discussion and _not_ yet agreed stuff!=0A=0A=0A=0Aa.) create a=
 new extcdi-2.x branch. Trunk will (for now) still remain CODI-only! We wil=
l still ship bug fixes for 1.x but all new feature development is done in D=
eltaSpike.=0A=0A=0Ab.) add deltaspike-core-api and deltaspike-core-impl as =
dependencies to CODI=0A=0Ac.) remove our own ProjectStage stuff. People sho=
uld use the drop-in replacement from DS instead=0A=0Ad.) provide a small Ex=
tension which rewrites CODI @ProjectStageActivated annotations to DS @Exclu=
de. Of course log a warning that people should change their impl because th=
ey are using a deprecated functionality=0A=0Ae.) remove all functionality f=
rom CODI core which got moved to DS. If possible create a compatible wrappe=
r. Most of the time the effort for end users should just contain changing a=
n import package.=0A=0A=0Af.) rewrite all ee modules to make use of the del=
taspike-core stuff instead.=0A=0Ag.) if DeltaSpike ships a new feature whic=
h replaces a CODI feature, we will =0A=0A=0A=0AAs 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 possibl=
e for the end users, we will really take care about binary compat and featu=
re changes. Thus I like to propose a strict version schema: [major nr].[min=
or nr].[bugfix nr]=0A=0A=0Amajor 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 De=
ltaSpike we will increment this nr. This indicates that the user might need=
 to change some import package or do some other small change.=0A=0A=0Abugfi=
x nr =3D This is intended for being incremented when we ship a new COMPATIB=
LE 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 d=
oesn't like to update to a 2.4.0, then he is very welcome to ship a patch a=
nd 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). =0A=0A=0A=0AThis means we will create an own b=
ranch 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 no=
wadays).=0A=0A=0A=0AWDYT?=0A=0A=0ABtw, 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 th=
at a lot of companies use it (even though they never speak up on this list =
or make any public announcement about it).=0A=0A=0ALieGrue,=0Astrub=0A