On 19/03/2020 03:56, JAVIER MIGUEL RODRIGUEZ wrote:> I fully agree with this: > >> Please consider holding off on removing features for the next major >> release, 2.4.0 instead. It makes sense to retain, in as much as is >> possible, feature backwards compatibility across a major release.I'm astonished that features are being removed in a dot release as well, no other major project does this, hell, most don't like adding new features in dot releases let alone stripping them out. None of the listed changes affect me that I can see, but I've been around a long time and I'm flabbergasted that someone actually approved this on dot release. Now although there is no real need for them to further upgrade to ensure business continuity, if a serious exploit is released in the wild they highly likely will get bitten. Stripping everything else at once in a new major is perfectly acceptable, and, is the norm. -- Kind Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate any part of this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20200319/e5c96df3/attachment.html>
On 18-03-2020 22:55, Noel Butler wrote:> On 19/03/2020 03:56, JAVIER MIGUEL RODRIGUEZ wrote: > >> I fully agree with this: >> >>> Please consider holding off on removing features for the next major >>> release, 2.4.0 instead. ?It makes sense to retain, in as much as is >>> possible, feature backwards compatibility across a major release. >> >> >> > I'm astonished that features are being removed in a dot release as well, > no other major project does this, hell, most don't like adding new > features in dot releases let alone stripping them out. > > None of the listed changes affect me that I can see, but I've been > around a long time and I'm flabbergasted that someone actually approved > this on dot release. > > Now although there is no real need for them to further upgrade to ensure > business continuity, if a serious exploit is released in the wild they > highly likely will get bitten. Stripping everything else at once in a > new major is perfectly acceptable, and, is the norm.I have to say that I also cannot understand why you're going to remove features from a dot release. You can give the heads-up here, but it is not common-practice and will very likely break a lot of setups. It's understandable that you want to remove features that are hardly used or maintained, but not in a dot release. Please reconsider this removal, and remove those features as of the next major release. -- Kind regards, Rob
Hi!
We appreciate the feedback we have received from everyone, and we have discussed
it internally.
The features we are removing are deprecated and should not have been used
anymore. They all have alternatives that work equally well if not better.
For the authentication drivers, you can use passwd, pam and Lua as replacements
for most of them. Lua in particular allows good integration
with just about any external system. VPopmail can be replaced with SQL
authentication.
For password schemes, we have guide:
https://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes
Memcached should be replaced with redis.
The expire, autocreate and autosubscribe plugins can be replaced with namespace
settings:
namespace {
mailbox Name {
auto = create or subscribe
autoexpunge = value
}
}
See the mailbox configuration documentation at
https://doc.dovecot.org/configuration_manual/namespace/#mailbox-settings.
fts-squat can be replaced with Solr. squat has been considered obsolete (and
that has been also indicated in documentation) since at least 2014.
After discussing it internally, we decided to postpone the xz removal for the
time being. We understand the complexity of migrating away from it, so we want
to give more time to do that.
However beware that there are memory management issues in liblzma and we
consider it unsafe to use. Feel free to use any of the other supported
compresion algorithms instead. (We are also adding zstandard support in 2.3.11.)
You can switch your repository configuration to not use the ce-2.3-latest
symlink, but rather to use a specific version (e.g., ce-2.3.10) giving you the
control about when the system upgrades to a new version without missing out on
CVE fixes in updated packages.
Finally, I want to point out that we will be happy if someone wants to start
maintaining a feature we are planning to remove.
Aki