Ehlo, With last release we made the experimental filters API available so that developers could start writing filters, spot shortcomings in the API and let people test them to try to spot bugs we missed.
As we expected, several issues were spotted and we work on fixing them. This is all great but lately a trend has emerged: People find a filter that does what they want and they completely ignore the fact that they are experimental because it solves an immediate need. We could care less, but now we see more and more situations where a user has a question regarding a feature and someone will just tell them about this or that filter which "solves" their issue. Now that filters have been packaged by third-parties, it gets worse. New users may be told by someone to run filter-foobar, they will find it in their package manager, install it, and end up with an unstable system without even knowing they're running experimental code... So... We don't want to disable filters, we're at a stage where it needs to run on some *aware* user machines, and we can't simply stop publishing as we now have lots of users who would experience a regression on their setup. I have fixed the configure to make it VERY obvious for packagers that an add-on is not meant to be used on a stable setup. I have also added a very annoying runtime warning that will trigger when a filter is called and which will make it clear in logs that a filter is being used despite being experimental. I hope it helps reduce the wreck that my mailbox has become :-) -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
