Hi!
I've noticed a certain problem in our workflow that I'd like to discuss.
>From time to time, we deprecate certain APIs in core or extensions. The
idea of deprecation is that we have gradual transition - existing code
keeps working, and we gradually switch to the new API over time, instead
of removing old API at one sweep and breaking all the existing code.
This is the theory, and it is solid.
Also, we have phan checks on the CI builds, which prevent us from using
deprecated APIs. Right now if phan detects deprecated API, it fails the
build.
Now, combining this produces a problem - if somebody deprecates an API
that I use anywhere in my extension (and some extensions can be rather
big and use a lot of different APIs), all patches to that extension
immediately have their builds broken - including all those patches that
have nothing to do with the changed API. Of course, the easy way is just
to add @suppress and phan shuts up - but that means, the deprecated
function is completely off the radar, and nobody probably would remember
to look at it again ever.
I see several issues here with this workflow:
1. Deprecation breaks unrelated patches, so I have no choice but to shut
it up if I want to continue my work.
2. It trains me that the reaction to phan issues should be to add
@suppress - which is the opposite of what we want to happen.
3. The process kind of violates the spirit of what deprecation is about
- existing code doesn't keep working without change, at least as far as
the build is concerned, and constantly @suppress-ing phan diminishes the
value of having those checks in the first place.
I am not sure what would be the best way to solve this, so I'd like to
hear some thoughts on this from people. Do you also think it is a
problem or it's just me? What would be the best way to improve it?
Thanks,
--
Stas Malyshev
smalyshev(a)wikimedia.org