Am 28.08.20 um 21:47 schrieb Physikerwelt:
I appreciate your argument, however, I think the
deprecation policy
will be used in good faith. Fast deprecations are really helpful for
code that is not been used. If one expects that a feature is used in
hidden code probably people will not depreciate it too fast,
especially if there is a lot of visible code to refactor.
Hi Moritz!
I think you are toughing on the core of the issue: We need to figure out mow
much we care about "hidden usages" in code that is not shared back to the
community.
For a long time, the answer has been "very much", so we worked as if MediaWiki
was a framework developed for other people's use, providing a maximum of
backwards compatibility. However, this comes with a very real cost in terms of
development speed and code complexity.
The other extreme would be saying "not at all". Then we wouldn't need
release
notes. Maybe we wouldn't even need releases. That would be a rather harsh.
Perhaps it would be helpful to be more specific about what code we are talking
about. I think that for code we release as standalone libraries, we should
ensure compliance with the principles of semantic versioning, and avoid
inconvenience for 3rd party users.
However, for MediaWiki core, I have come around to thinking that we should not
allow ourselves to be held back too much by the needs of "hidden usages". We
really need to modernize the codebase, and that means breaking changes. Dragging
along a compatibility layer means we cannot benefit from the changes we have
made until we can drop that layer. So I'd rather that be months, not years, as
it has been in the past.
So, for core, I think we should only care about usage in non-public code "a
little". In exchange, we should better support updating 3rd code that is public.
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation