james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincenzo Gianferrari Pini <vincenzo.gianferrarip...@praxis.it>
Subject Re: Switch to Loom 1.0RC3
Date Wed, 07 Sep 2005 16:27:11 GMT
Stefano Bagnara wrote:
>>Not totally true, as I think that some people (like myself) 
>>has been thoroughly testing even in production the contents 
>>of svn. Specially after Noel's work in May, which has been a 
>>major (and potentially risky) update impacting the whole 
>>system ... And James looked quite stable after that.
> We also, in the last month:
> - updated all of our libraries
> (cornerstone/avalon/excalibur/dnsjava/javamail)
> - updated phoenix (so as you can see we already "changed" the container)

For me, a container change *has a big impact* (specially because it is a partially "dead"
container outside of our 
control), and I was very "nervous" during Noel's work on May until my tests (better, my production
system carefully 
watched for weeks) showed that everything was running fine.
I'm again a little bit nervous now after the August container changes, and I would become
a little bit more nervous if 
another change in this area should come *before creating a new release*. If what we have now
is not enough to call it 
2.3.0, let's call it 2.2.x. Although I feel that all this container change makes is worth
to be called 2.3.0.

> - added derby support and we're planning to make it the default instead of
> file repositories.
> - changed today the mail repositories notify/synchronization
> I think all of this have to be tested a lot and can impact the stability
> more than the container.
> BTW, this is my opinion.
> The last one (notiy/synchronization) in my opinion is the most critical.

Agreed. I remember Noel fixing more than two years ago a bug in this area that ran me crazy
for several months, very 
hard to track.
> The main thing is that we are not near to a release because we don't even
> have a release plan by now and we just talked about doing a release.
> In the best scenario we probably will be ready to prepare the first ALPHA in
> a month: probably more as we haven't agreed on the roadmap for this release.

This way IMHO we will never get to a release, because we will be introducing more bugs to
fix than fixing old ones.
IMHO we should make no more architectural changes, start testing immediately and release *as
soon as possible* a safe 
release. The more we wait, less people around will do any *real* testing.
This is what I think is the release plan we should agree upon. And we have been talking about
doing a release since 
several months.
And this is why I recently said that we should stop and take a breath... :-) By stopping I
mean slowing down introducing 
architectural changes, that can introduce bugs very hard to track down. Any "minor" enhancement
or feature can be 
obviously added.

After that, let's go for 2.3.1, 2.4 or 3.0.

BTW, compared to the past, we haven't formally release alpha releases, but milestones did
exist although not set in svn.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message