Stefano Bagnara wrote:
> That said you once said that we could deprecate things in a version and
> change them in the following one.
I seem to recall saying that is what a particular large vendor does, and I
wouldn't have much of an issue with it. But if a user raises a concern, I'd
support it for as long a reasonable. Besides, that vendor might do a major
release every 2 years or so, so that gives people a multi-year window. If we
are deprecate it in 2.3 and remove it in 3.0, that could be way too short a
period of time.
> 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.
*I* don't want to deprecate things? I'm the one who listed them. I'm happy to
list as deprecated things that we agree we want to remove. Of course, we
should list the replacement or that it will simply go away.
As for when to actually remove it, odds are that if I am willing to deprecate
it, I either no longer use it or already plan to use the replacement. But as
Vincenzo notes, there are other users.
> 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.
Then we agree.
> > 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!
> I don't even know who Mark Imel is, and what is the Mark Imel's list
> manager.
Mark Imel is a committer who hasn't been around in a while, but he contributed
the bulk of the modular, command-based, Mailing List Manager, and I think that
it is nice to remember people for their work.
> Btw my personal opinion is that James needs new features
> - IMAP
Agreed. And we have a lot of protocol support for it. I have an idea for
resolving the store issue.
> - ESMTP extensions support
> - Flexible and easy to extend fastfail
Hopefully, the modular protocol handler approach will help with both, along
with a switch to MIME4J for most of our message handling needs.
> - Better integration with LDAP and other services
Same here. In fact, although I want more flexibility for message stores, I am
once again contemplating if we can switch to JNDI entirely for user
repositories.
> - High Availability
Agreed, which was part of what was underlying the spooler proposal I made
recently.
> 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.
I'd provide a migration path, and perhaps some simple tools (since those of us
who use JAMES in production would also need to convert our production systems).
> It is clear that we don't share this idea
Oh, it is? Which part?
> About this deprecation issue [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.
Oh, I want to mark it as deprecated, and see what feedback we get.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
