james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: LONG JAMES v2.4 Road Map
Date Fri, 15 Sep 2006 16:29:55 GMT
Bernd Fondermann wrote:
>> Bernd, this was by no means to be understood as an offense or anything
>> against other active contributors on this project. This List is neither
>> complete nor a concrete suggestion. Replace the Names in the Lists with
>> A, B, C, and D.
> -1. Not agreed. I favor all the committers working together on the
> current release. We don't want to split the community up. Other
> projects here at Apache are in deep, deep trouble just because of
> this!

I've proposed the "next-minor"/"next-major" because I don't see it as a 
split. It is simply a group of people that put efforts to consolidate 
some of the features we have in trunk, while new work in trunk is being 

So I don't think at this as a project fork, but simply a consolidation 
branch, like we did for 2.3. The main difference between 2.3 is that 
this time I already said I can't (and want) put my efforts on the 
consolidation branch. Nothing terrible at all, nothing to call home for.

Imho the 2 active trees rule we agreed in past is still valid: trunk is 
always the main active tree. We're waiting to close 2.3 so the 
next-minor can be started and only when next-minor will be closed we're 
going to open the next-major release.

Imho this make sense. We can't think we'll have the efforts of every 
committer for everything we decide to do. There are many James 
committers that did nothing since 2.1 but they still have the power to 
vote (even if they don't do this so often). As you said everyone should 
be able to do what he wants (by respecting the high-level project goals) 
and when he wants (and not being managed) and we should only try to 
synchronize/optimize our efforts.

Furthermore, I already wrote that the "split" could give our users the 
best results (3 releases in 6 months!!) and let everyone work on the 
preferred tree.

>> So do we/you want to deliver standards, or do you want to chase them?
> Is that related to IMAP? Hopefully, this will be added soon.

Unfortunately I guess that IMAP won't be included in next-minor or 
next-major, but we can only expect to be able to do some steps in that 2 
releases (it would be *really* cool if we were able to put experimental 
unstable support for imap in next-major but this is not realistic to me).


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

View raw message