You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2002/12/03 10:24:32 UTC

Re: Here is where we are divided


Stephen McConnell wrote:

>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Berin Loritsch wrote:
>>
>>> It appears that we are split down the middle on whether we want a
>>> clean slate or build on what we have.  Part of the problem is because
>>> we are afraid of what it would take to come to consensus.  As a result
>>> there are some potentially really cool things that we might be able
>>> to do with a clean slate that we might not see.  There is also the
>>> fear that we are abandoning our current users.
>>>
>>> First, the reassurances.  None of us want to abandon our current users.
>>> We aren't all masochistic/sadistic/whateveristic.  That is why any
>>> brand new development absolutely requires a compatibility layer.
>>>
>>> Next, the realities.  We have an existing framework that works.  It
>>> has a couple rough edges that we can't clean up because there is
>>> current software dependent on it.  They are not show-stoppers, but
>>> things that stick in some of our craws.  Any time we have new
>>> contracts that were not there before, we have a new version.  It is
>>> a question of degrees, but it is a new version nonetheless.
>>>
>>> Framework Version 4.2 means we keep everything we have already.  It
>>> means we don't smooth the rough edges.  It means we don't do anything
>>> radical.
>>>
>>> Framework Version 5.0 might be a smoking gun.  Emotions are high right
>>> now, which means that we might have to delay any hopes or dreams for 
>>> 5.0
>>> even longer.  Keep in mind it will always be an emotional prospect.
>>> However our attention can't be devided when we are discussing it.
>>>
>>> We either shoot for the moon, or we play it safe.
>>
>>
>>
>> I have not yet voted on this, but it seems that there is a deadlock, 
>> so here is my opinion.
>>
>> I think that complete rewrites are very dangerous, and must be done 
>> only as a last resort. They make code loose much of the information 
>> that's there, in bugfixes, patches and testing.
>>
>> On the other hand, things must continue to go forward, and things 
>> that obviously don't work must be rectified and changed.
>>
>> Avalon has still in minds of many a bad name about the heavy 
>> refactorings it did years ago. Avalon is stable, works well, but 
>> still developers remember what happened back then. I don't want this 
>> to repeat.
>>
>> So this is my opinion: let's go for *AValon* (V==5).
>>
>>                           *BUT*
>>
>> Let's build on 4.1. That means *not* change packagenames, *not* 
>> change class names just for the sake of it, *not* create new classes 
>> when the existing ones can do with proper deprecation.
>>
>> Let's bring out our issues and visions, understand what users need 
>> and we want; then take 4.1, package per package, discuss them, see 
>> what can be taken - and I'm sure it's most of it - and make AValon.
>>
>> +1
>
>
>
>
> a.ka. 4.2
>

I'm changing my mind.

My thinking is that starting this process withing the scope of A5 is 
probably better.  I have suficient investment in A4.x to make sure 
whatever happens - it will be rationale with respect to A4.x and I'm not 
about to drop 4.x support - but at the same time doing a A5 shift lets 
us to that quantum leap that we need to make make the new Avalon a success.

Consider me on board.

Cheers, Steve.



-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>