Noel J. Bergman wrote:
Sure: if we aggree that they should be removed then we should add a
"deprecate" tag in the current 2.3 release and remove them in our
trunk for the next release.
Have you noticed how slowly Sun *ever* removes deprecated code? I would remove
such optional pieces (matchers and mailets) only when there is a required
effort to keep the code, and no one wants to make that effort.
We are not Sun, James is an Apache product and not a Sun product, James
has different userbase from Sun Java language specification and virtual
machine specifications.
That said you once said that we could deprecate things in a version and
change them in the following one. I really don't care about this code: I
read that you thought we could deprecate it, I know that you never want
to deprecate things, so I thought it was really unused thing and as such
it was better to remove it from the codebase we are mantaining.
And I would move them to a new package, so that the only thing someone had to
do is add the package. That would probably satisfy both you and Vincenzo.
I'm satisfied even if we keep them forever ;-)
I was trying to be agile, nothing more.
PS: I don't know why Noel thinks they should be deprecated, I thought
that a better alternative existed or something similar
Yes, Mark Imel's list manager has long replaced the old one, but that does not
mean that other people aren't still using the old one!
--- Noel
I don't even know who Mark Imel is, and what is the Mark Imel's list
manager.
Btw my personal opinion is that James needs new features:
- IMAP
- ESMTP extensions support
- High Availability
- Better integration with LDAP and other services
- Flexible and easy to extend fastfail
And much more.
IMO if the cost to reach this goal is deprecate almost all we have now,
and broke upgrade compatibility to every single user we have now it
would be welcome anyway.
It is clear that we don't share this idea, but I don't think I need
lessons on how Sun manage its own products ;-)
About this deprecation issue. Imho it doesn't deserve so much words,
let's say you would like to deprecate some code and I reply with +++1.
If you don't want to deprecate it, well, I'm ok anyway.
Btw I don't see too much advantages in deprecating things that works if
the final goal is not to remove them: so I'm +0 in deprecating them if
there is not a goal to remove them.
Either way if we agree that the code should be deprecated I would prefer
to do that in 2.3.0.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
