Deprecating code ...

["Noel J. Bergman" <no...@devtech.com>]

Stefano wrote:

>>>>>> AvalonListserv.java (2 matches)
>>>>> AvalonListservManager.java (2 matches)
>>>> Obsolete and ready to deprecate, IMO.
>>> I love to remove code: can we remove those from trunk?
>>> Wait: deprecate != remove. I'm using AvalonListserv and 
>> AvalonListservManager quite extensively, and others may too.
>> This is an example of how caution must be applied to help
>> users upgrade.

> 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.

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.

> 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


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

Re: Deprecating code ...

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

Noel J. Bergman wrote:

>Stefano Bagnara wrote:
>
>  
>
>>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.
>
>
>  
>
My way of thinking is to deprecate whatever is felt to be out of the 
common main view of the direction to go, so the users know that they 
should not count on them for new things, but not to delete them until it 
is cumbersome to mantain.

Vincenzo

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

RE: The Imap store issue WAS: Deprecating code ...

[Joachim Draeger <jd...@joachim-draeger.de>]

Am Donnerstag, den 13.07.2006, 20:31 -0400 schrieb Noel J. Bergman:

> > 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.

I'm very curious to hear about it! I tried to collect the requirements
from James, Imap and Javamail and put it into interfaces.
But as Bernd remarked that should be concepts of whole James and I
really can't do that all on my own.

Joachim



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

RE: Deprecating code ...

["Noel J. Bergman" <no...@devtech.com>]

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Deprecating code ...

[Stefano Bagnara <ap...@bago.org>]

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org