james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Next 2.x release
Date Mon, 06 Nov 2006 01:20:47 GMT
Stefano Bagnara wrote:

> Well, I believe in you, but I also know that you are the only supporter
> of the "next-minor"

Actually not, but I believe that you've talked most people to death on it.
That doesn't work on me.

> and you are so busy that you have to vote on the "James Server future
> releases/road maps" vote I started in October the 25th.

Actually, I just prioritize my time.  First, I was at a conference, and then
I was fixing fictional bugs because my production server shared my

> So I think it is safer for the project if we keep open the way to
> a 2.3.1 in case you'll be busier than you think now and we have to
> cancel next-minor.

My time to waste.

> The doubts you later expose about "next-major" are the same doubts I
> have about your next-minor: I understood you want handlerapi-v2 in
> "next-minor"

In the first out?  I doubt it.  Ever?  That would all depend on just how bad
the code is that comes over from trunk.

> I will be really happy if you do [the handlerapi-v2], because it is
> the bigger missing piece for next-major.

That and the scheduler/spooler changes.  I was going to work on the handler
this week, but ended up fixing the other two bugs instead.  But as soon as I
finish packing and invoicing, back to the handler API.  :-)

> I think timeframe is a key part of the next-major release, and we'll
> probably postpone some of the feature expected to be in next-major
> if they are not ready for the estimated branch time.

It is not a matter of features.  If you really want to have a stable release
anytime in early 2007, we're going to have to get serious, compare v2.3.0
with trunk, branch trunk with largely the same code that is in v2.3.0 except
for known and reviewed improvements, and go from there.  Some of us are
going to have to review changes --- line for line --- between the stable
code and whatever we copy from trunk.  Until then, I'm just going to view
trunk as an unstable dumping ground.

> "next-major" had a lot of supporter in the vote I discussed above, so I
> expect a lot of effort to make that real in the estimated timeframe.

Actually, no.  What people said was that they figured that you'd be doing
it.  Re-read the e-mails.

For example, I would not expect to see the refactored Mailet API in a
production release anytime soon.

	--- Noel

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

View raw message