On Sat, Mar 06, 2004 at 07:05:01AM +0000, Tim Larson wrote: > On Fri, Mar 05, 2004 at 11:41:15PM +0000, Pier Fumagalli wrote: > > On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote: > > >Tim Larson wrote: > > >>On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: > > >>> Package: org.apache.cocoon.cforms > > >>> > > >>>here I would go "forms" instead. package naming is where the estate > > >>>really is, where class collissions might happen. > > >> > > >>I understand how this seems like a good place for the battleground, > > >>but to introduce a new winner it looks like this would force us to > > >>break code compiled against the previous major version because we > > >>would be stealing the class and interface names for the new version. > > >>Does the new block system somehow solve this problem like via > > >>classloaders or something else? > > > > > >eh, very good question, actually. I spent a few hours discussing with > > >Pier about this yesterday over IM. Pier, as usual, sees the very core > > >problem and I always miss ;-) > > <snip long, complex classloading/dependency discussion/> > > Ok, so to sum up the version/classloading discussion, this plan > (using 'forms' for the package naming) involves burning the users > on major version upgrade by for most practical purposes breaking > the previous major forms version when introducing the new version. > > I agree with the idea of forcing core developers to choose between > adding enhancements incrementally versus making a *major* effort to > prove that their new revolutionary version deserves to unseat the > current framework, but making things tough for the users is going > too far. I must be missing something, would somebody enlighten me?
I talked with Antonio on IRC and he had a good idea (IMHO) for this. Make the package name start as either o.a.c.forms or o.a.c.forms1 and a new major version can go to o.a.c.forms2. This preserves the ONE-and-only current forms framework concept (identified by the current stable version number), while not introducing any classloading version problems. Also, the actual class names and interface names are not polluted with version numbers. WDYT? --Tim Larson
