Noel J. Bergman wrote:
Danny Angus wrote:
Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Sorry I don't understand this message. I understood we defined the
following:
2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
release something if needed (the unbounded cache and the connection
accepting problem are good candidate to decide we need it).

I doubt that we'll ever do this, since it would be subsumed by:

Well, I believe in you, but I also know that you are the only supporter of the "next-minor" 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. 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.

next-minor: the release you said you want to work and that will be based
on 2.3 branch (but not the 2.3 branch itself) and you want to backport
things from trunk (to be released in 1-2 months).

which is what I'm working on.  And of course it would be from the v2.3
branch, which is why it still exists.  So far the list includes:

  - removal of InetAddress cache
  - connection accepting fix
  - per IP connection enhancement

The latter two are pending Norman's changes for the last, since those files
are identical between v2.3 and trunk.

As you are the only active supporter of this next-minor release you're almost free to do everything you want preparing the next-minor proposal, but please work in the "next-minor" branch and not in the "v2.3" branch.

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" and it will be an hard task to complete that branch and consolidate it to be released in a month or 2. Believe me: I will be really happy if you do this, because it is the bigger missing piece for next-major.

next-major: the release we are currently preparing on trunk and that
we'll branch soon (in 1-2 months).

I doubt that timeframe, but timeframe is irrelevant.

        --- Noel

Well, 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. This is my current feeling about this issue, but we'll of course discuss together the issue in the first weeks of december. "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.

That said, let's keep working, we all have a lot to do in our branches :-) and it is really cool to see so much different authors in the commit notifications!

Stefano


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

Reply via email to