[yast-devel] Breaking the API
In our attempt to delete dead code, we recently removed some methods from the UsersSimple API[1]. I'm all for it (actually, I pushed for it) and I would happily remove all the methods that are not longer called from the YaST code. Death to all Perl code! The problem is that we are not the only users of our own legacy APIs. With UsersSimple it should be fairly safe because the module is supposedly only used during installation (although you can always get surprised by the extremely hacky SAP-related modules and scripts). But with other modules (say /Network/) is not so clear. We should have a mechanism to deprecate API methods and to delete them in a way in which: - We keep track of what we remove in every version bump - Interested parties (like the maintainers of the SAP modules) can get alerted of deprecation/removal, so they can adapt their stuff or oppose to the change. Otherwise, cruft will be there forever because we are too afraid to remove it. Any plan or suggestion? Cheers [1] https://github.com/yast/yast-users/pull/86 PS.- After writing $SUBJECT, I couldn't resist https://www.youtube.com/watch?v=L397TWLwrUU -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
We should have a mechanism to deprecate API methods and to delete them in a way in which: - We keep track of what we remove in every version bump - Interested parties (like the maintainers of the SAP modules) can get alerted of deprecation/removal, so they can adapt their stuff or oppose to the change.
Otherwise, cruft will be there forever because we are too afraid to remove it.
What I usually do is that I break the code in early stages of SLES development (pre alpha or so). As "real" testing comes in late stages it is too old to put it back as some other things usually depends on it. Yes, it is a bit stressing from P1s point of view, but otherwise everyone needs just the one old method I want to drop ;-)
Any plan or suggestion?
During development stage 1 (e.g. SLE-12-SP2) collect suggestions for removals in development stage 2 (SLE-12-SP3). The list can be frozen and e.g. turned into a feature (if needed) before starting stage 2.
Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (2)
-
Ancor Gonzalez Sosa -
Michal Filka