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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
