Honestly if you want a depreciation policy, warnings need to be omitted for
at least one 1.x version. Anything less than that is pointless from an end
user perspective. We tend to wait for final releases to limit bug exposure.
If something breaks, and it's not clear exactly what the cause is, using
incremental updates to figure out the breakage is the solution normally
applied. One of the key reasons to use a depreciation policy is to limit
the breakage that can happen, if the Mediawiki culture is shifting to a
screw non-published extensions policy might as well not have a depreciation
policy. However if the historical spirit of MW is maintained having such a
policy is critical. Mediawiki is re-used by a lot of different groups, not
all of them are able to or are willing to publish extension code for a
number of reasons. Taking the "Not my Problem" approach leaves a sour taste
in my mouth. Honestly if you cannot maintain compatibility for at least one
release cycle, how much damage are you going to create?
On Tue, Sep 1, 2020 at 8:58 AM Daniel Kinzler <dkinzler(a)wikimedia.org>
wrote:
Hi Arthur!
We were indeed thinking of different scenarios. I was thinking of someone
who
runs a wiki with a couple of one-off private extensions running, and now
wants
to update. They may well test that everything is still working with the new
version of MediaWiki, but I think they would be unlikely to test with
development settings enabled. The upgrade guide doesn't mention this, and
even
if it did, I doubt many people would remember to enable it. So they won't
notice
deprecations until the code is removed.
I understand your scenario to refer to an extension developer explicitly
testing
whether their extension is working with the next release, and try it in
their
development environment. They would see the deprecation warnings, and
address
them. But in that scenario, would it be so much worse to see fatal errors
instead of deprecation warnings?
This is not meant to be a loaded question. I'm trying to understand what
the
practical consequences would be. Fatal errors are of course less nice, but
in a
testing environment, not a real problem, right? I suppose deprecation
warnings
can provide better information that fatal errors would, but one can also
find
this information in the release notes, once it is clear what to look for.
Also note that this would only affect private extensions. Public extensions
would receive support up front, and early removal of the obsolete code
would be
blocked until all known extensions are fixed.
Thank you for your thoughts!
-- daniel
Am 31.08.20 um 20:54 schrieb Arthur Smith:
Hmm, maybe we're talking past one another
here? I'm assuming a developer
of an
extension who is interested in testing a new
release - if we have a
version that
has things deprecated vs completely removed, that
allows a quick check
to see if
the deprecated code affects them without going
back into their own code
(which
may have been developed partly by somebody else
so just reading release
notes
wouldn't clue them in that there might be a
problem).
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l