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:[EMAIL PROTECTED]
http://www.osm.net




-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Reply via email to