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>