Jason van Zyl wrote:
> On 6/26/01 10:04 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > i would like to check in my changes to the security system:
> > (/proposals/sec)
> >
> > * om/peer classes are torque generated
> > * SecurityEntitiy (interface) is used instead of SecurityObject (abstract
> > class)
> > * om classes implement SecurityEntity, Comparable
> > * TurbineMapBuilder is no longer used (MapBuilders are generated)
> >
> > martin
>
> I'm +1 on the method but where are we going to put these changes?
+1
> They will first go in HEAD, but do we want to back port them
> to 2.1. I would prefer if we didn't as this would give people
> a big incentive to move forward and I'm worried about the
> maintenance problem between the proposal for for security
> in 2.2 and what people are using in 2.1.
2.1 should receive only bugfixes. I think that backporting every
new feature to past releases is a waste of effort. 2.1 is for supporting
pepople who already have applications, and would like to fix any
security holes or take benefit of performance improvements by simply
dropping 2.1.<minor> jars into their WEB-INF/lib.
New cool features should go into 2.2, and people must decide for
themselves
when they want to switch. (setting a -pre tag on the HEAD is probably
the
right moment to begin evaluating the new version).
> If we moved quickly to get an alpha of 2.2 out in a couple
> of weeks could we keep these changes for 2.2 and forget about
> back porting them?. I know the changes are pretty much backward compatible
> but it's quite a radical change from what's in 2.1 now.
That's good. 2.2 is supposed to be radicaly better than 2.1, right?
Rafal
--
mgr inz. Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
