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 <dkinz...@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@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
