Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > As I said long ago, if you want to move trunk to 2.4, we should
> > review every difference. Then, if we agree that each one
> > represents a suitable risk/reward, fine.
> I'm sorry but (as I also said long ago) I'm on the opposite position
> about the 2.4 roadmap.
So what is your position? That we should simply dump trunk on users without
proper review? Without comparing it to what we have spent so long testing
and reviewing in the 2.3 branch?
> We've just finished with a lot of efforts to put out a stable release to
> replace the old 2.2.0.
Exactly.
> Now I think that not only we should include everything we have now in
> trunk, but we should also define a period of feature development where
> we try to put in every cool feature we are able to develop in this time
> with one single restriction: keep storage compatibility.
When do you expect to put that out?! I'm talking about a plan that allows
us to put out a stable release very few months with carefully made changes,
and you just want to core dump! I do not agree to that approach.
> My proposal is to start at least 2 months of free development in trunk
> and then create the 2.4 branch to start the consolidation process.
And if we do it my way, we can release 2.4 in less than 2 months. And work
on v3 at the same time. And I want to branch soon, so that we can start
working on the major changes that we should be doing for v3, and not just
the safe but useful changes for v2.4.
> Everything we currently have in trunk deserve inclusion in the next
> release and much more of this.
Wrong. Most of what is in trunk has had a fraction of the review and
testing that we have spent on v2.3, and you're talking about a free-for-all
of development.
> Furthermore I would consider a big mistake to try to release 2.4 as a
> 2.3 + new fastfail things, because new fastfail things are still in
> progress and not mature enough
And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such
"still in progress and not mature enough" things, not just fast-fail. Maybe
we decide that fast-fail isn't mature enough yet. As you say:
> There is a lot of stuff that has been removed by the 2.3 branch but
> should really fit the 2.4 branch: database read/write streaming (we have
> write streaming in 2.3 but disabled by default because we had no time to
> test it enough), spool manager refactorings, 8bitmime (try again with
> new javamail fixes). We should refactor pop3 to follow the same smtp
> handlerchain pattern (and maybe do the same for remotemanager and nntp).
> We could try to include easier virtualhosting support, support for APOP
> and much other features that don't introduce storage incompatibility
> problems.
Not all of those share the same level of testing, value or urgency, and yet
you just want to dump it all on users as if we had carefully developed and
tested them?
You've just ennumerated a whole raft of issues. We should examine each one
to decide if THAT SPECIFIC PIECE is stable enough to go into the release,
not conflate a dozen or more items.
So we can start with ones that we all agree ARE stable enough to go into
v2.4, and not just dump a load of immature code on top of our stable
release.
> A last reason to not start a 2.4 branch now and to not start a selective
> merge job is that we are not sure that 2.3.0 would not need a 2.3.1
> release in a month
If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice. I
want to start using this stuff ASAP, not after another year of development
and testing.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
