You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Tellier Benoit <bt...@apache.org> on 2019/11/11 07:36:10 UTC
Upcoming 3.5.0 release + deprecation/removal plan
Hi all,
Having fixed, or working on fixes that users did report to us, there is
a big list of meaningful features stacking up in the changelog [1].
Thus I would propose us to pursue a release of James server version
3.5.0 by the end of November.
As with most recent releases, that is also the opportunity to clean up
the project a bit.
I propose the following removals in 3.5.0:
- mailet/api MailAddress (unused , deprecated in 2017 see JAMES-2138)
- protocols/smtp MailAddress (unused , deprecated in 2017 see JAMES-2138)
Also, given a limited workforce, we cannot keep up with every aspects of
the James project. As such, dropping unmaintained and often unused part
of the James project is a sane habbit, in the absence of devoted
contributors.
As such, I propose to deprecate in 3.5.0, targeting a removal in 3.6.0
the followings:
- james-server-mailet BayesianAnalysis + BayesianAnalysisFeeder +
JDBCBayesianAnalyzer.
mailet/ai mailets to be used instead.
- ToRecipientFolder.
WithStorageDirective + LocalDelivery to be used instead.
This will limit user misunderstandings
- mailbox/zoo-seq-provider.
Not exposed to the end user.
- mpt/antlib + mpt/mpt-maven-plugin + mpt/app
Not aware of usages, not exposed to users
Of course, if you are interested into maintaining the following
components, you should reach us, your contributions are going to be much
welcomed!
Do you have items to add to the list? Remarks?
I hope we can set up a vote by the end of the week.
Regards,
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Upcoming 3.5.0 release + deprecation/removal plan
Posted by Tellier Benoit <bt...@apache.org>.
My bad, answer inlined...
On 13/11/2019 15:24, Matthieu Baechler wrote:
> Hi Benoit,
>
> It looks like you forgot the answer to the mailing list.
>
> On Wed, 2019-11-13 at 14:46 +0700, Tellier Benoit wrote:
>> Hi Matthieu
>>
>> On 12/11/2019 15:19, Matthieu Baechler wrote:
>>> Hi Benoit,
>>>
>>> On Mon, 2019-11-11 at 14:36 +0700, Tellier Benoit wrote:
>>>> [...]
>>>>
>>>> I propose the following removals in 3.5.0:
>>>>
>>>> - mailet/api MailAddress (unused , deprecated in 2017 see JAMES-
>>>> 2138)
>>>> - protocols/smtp MailAddress (unused , deprecated in 2017 see
>>>> JAMES-
>>>> 2138)
>>>
>>> Are you sure about the JIRA number?
>>
>> Sure, that's the commit message prefix used for marking deprecation.
>
> Here https://issues.apache.org/jira/browse/JAMES-2138 the issue title
> is: "Implement Groups WebAdmin API"
>
A git blame in
protocols/smtp/src/main/java/org/apache/james/protocols/smtp/MailAddress.java
Reports:
JAMES-2138 move MailAddress to a new james-core project move james.core
package to james.server.core to avoid conflict
Author: Matthieu Baechler
Date:04/09/2017
I'm very glad that in two years we achieved a better issue splitting.
>>> Also, what's wrong about having several instances of a given
>>> concept?
>>>
>>> I mean, do you want James core code to be unable to change the
>>> MailAddress public API because it would break API stability for
>>> users?
>>>
>>> Using the same object everywhere means you introduce coupling and
>>> coupling is not always a good thing.
>>>
>>> Could you elaborate why you think coupling protocols/smtp,
>>> mailet/api
>>> and james/core is a good thing? (pros/cons)
>>
>> Coupling protocols/smtp, mailet/api and james/core are already
>> coupled
>> as mailet/api & protocols/smtp extends james/core MailAddress.
>
> The fact we did something in the past doesn't mean we can't undo it
> now.
>
>> I take backward compatibility argument for keeping using
>> "MailAddress"
>> in user implemented extensions.
>>
>>>> [...]
>>>>
>>>> As such, I propose to deprecate in 3.5.0, targeting a removal in
>>>> 3.6.0
>>>> the followings:
>>>>
>>>> - james-server-mailet BayesianAnalysis + BayesianAnalysisFeeder
>>>> +
>>>> JDBCBayesianAnalyzer.
>>>> mailet/ai mailets to be used instead.
>>>
>>> Did you evaluate each package? What is the rational to choose one
>>> rather than the other?
>>
>> After digging on the mailing list archives:
>>
>> - James server code regarding this dates from 2006.
>> - Mailet AI module inception dates 2011.
>>
>> The code is very similar and moistly duplicated. Thus keeping the
>> most
>> recent and maintained version sounds legitimate.
>
> +1
>
> [...]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Upcoming 3.5.0 release + deprecation/removal plan
Posted by Matthieu Baechler <ma...@apache.org>.
Hi Benoit,
It looks like you forgot the answer to the mailing list.
On Wed, 2019-11-13 at 14:46 +0700, Tellier Benoit wrote:
> Hi Matthieu
>
> On 12/11/2019 15:19, Matthieu Baechler wrote:
> > Hi Benoit,
> >
> > On Mon, 2019-11-11 at 14:36 +0700, Tellier Benoit wrote:
> > > [...]
> > >
> > > I propose the following removals in 3.5.0:
> > >
> > > - mailet/api MailAddress (unused , deprecated in 2017 see JAMES-
> > > 2138)
> > > - protocols/smtp MailAddress (unused , deprecated in 2017 see
> > > JAMES-
> > > 2138)
> >
> > Are you sure about the JIRA number?
>
> Sure, that's the commit message prefix used for marking deprecation.
Here https://issues.apache.org/jira/browse/JAMES-2138 the issue title
is: "Implement Groups WebAdmin API"
> > Also, what's wrong about having several instances of a given
> > concept?
> >
> > I mean, do you want James core code to be unable to change the
> > MailAddress public API because it would break API stability for
> > users?
> >
> > Using the same object everywhere means you introduce coupling and
> > coupling is not always a good thing.
> >
> > Could you elaborate why you think coupling protocols/smtp,
> > mailet/api
> > and james/core is a good thing? (pros/cons)
>
> Coupling protocols/smtp, mailet/api and james/core are already
> coupled
> as mailet/api & protocols/smtp extends james/core MailAddress.
The fact we did something in the past doesn't mean we can't undo it
now.
> I take backward compatibility argument for keeping using
> "MailAddress"
> in user implemented extensions.
>
> > > [...]
> > >
> > > As such, I propose to deprecate in 3.5.0, targeting a removal in
> > > 3.6.0
> > > the followings:
> > >
> > > - james-server-mailet BayesianAnalysis + BayesianAnalysisFeeder
> > > +
> > > JDBCBayesianAnalyzer.
> > > mailet/ai mailets to be used instead.
> >
> > Did you evaluate each package? What is the rational to choose one
> > rather than the other?
>
> After digging on the mailing list archives:
>
> - James server code regarding this dates from 2006.
> - Mailet AI module inception dates 2011.
>
> The code is very similar and moistly duplicated. Thus keeping the
> most
> recent and maintained version sounds legitimate.
+1
[...]
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Upcoming 3.5.0 release + deprecation/removal plan
Posted by Matthieu Baechler <ma...@apache.org>.
Hi Benoit,
On Mon, 2019-11-11 at 14:36 +0700, Tellier Benoit wrote:
> Hi all,
>
> Having fixed, or working on fixes that users did report to us, there
> is
> a big list of meaningful features stacking up in the changelog [1].
>
> Thus I would propose us to pursue a release of James server version
> 3.5.0 by the end of November.
>
> As with most recent releases, that is also the opportunity to clean
> up
> the project a bit.
>
> I propose the following removals in 3.5.0:
>
> - mailet/api MailAddress (unused , deprecated in 2017 see JAMES-
> 2138)
> - protocols/smtp MailAddress (unused , deprecated in 2017 see JAMES-
> 2138)
Are you sure about the JIRA number?
Also, what's wrong about having several instances of a given concept?
I mean, do you want James core code to be unable to change the
MailAddress public API because it would break API stability for users?
Using the same object everywhere means you introduce coupling and
coupling is not always a good thing.
Could you elaborate why you think coupling protocols/smtp, mailet/api
and james/core is a good thing? (pros/cons)
> Also, given a limited workforce, we cannot keep up with every aspects
> of
> the James project. As such, dropping unmaintained and often unused
> part
> of the James project is a sane habbit, in the absence of devoted
> contributors.
>
> As such, I propose to deprecate in 3.5.0, targeting a removal in
> 3.6.0
> the followings:
>
> - james-server-mailet BayesianAnalysis + BayesianAnalysisFeeder +
> JDBCBayesianAnalyzer.
> mailet/ai mailets to be used instead.
Did you evaluate each package? What is the rational to choose one
rather than the other?
> - ToRecipientFolder.
> WithStorageDirective + LocalDelivery to be used instead.
> This will limit user misunderstandings
>
> - mailbox/zoo-seq-provider.
> Not exposed to the end user.
This vote already happened in july
> - mpt/antlib + mpt/mpt-maven-plugin + mpt/app
> Not aware of usages, not exposed to users
+1
Cheers,
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org