5 ms·
> Paul Moore noted that marking it as deprecated did not work, nor did ceasing releases in 2015; "I'm not at all sure 'tell people not to use it' is a viable st
by bhaak 4y ago
> Paul Moore noted that marking it as deprecated did not work, nor did ceasing releases in 2015; "I'm not at all sure 'tell people not to use it' is a viable strategy for getting marked as 'not critical'."
Apparently you need to encode some dead man switch in your code if you want to stop supporting it.
Like blowing up X years after the last release or deliberately not working on some future version of Python/Ruby/whatever. But OTOH these automatisms are more code and code that might go off when they shouldn't. They make code more brittle.
Then somebody would need to actively step in and change the code to make it work again.
- cpeterso 4y agoEven a dead man switch is not enough. jwz added a "WARNING: This version is very old! Please upgrade!" time bomb message to xscreensaver's about dialog and Debian removed the warning code instead of upgrading to the fixed version of xscreensaver. Google "I would like Debian to stop shipping XScreenSaver" for details.
- temac 4y agoDebian is taking care of security maintenance of the software they ship. Now: maybe they will do a poor job of it, but that's another issue than intent; some users misdirect support requests to the upstream, but unless Debian version is misleading them, that's a problem with the users. The point of free software is to be free. If you do not wish people to be allowed to use and maintain it, and if you wish to have the possibility to "unpublish" or make old version non-free, you should use a non-free licence to begin with.
- thechao 4y agoI would argue that removing the warning triggers the "you touched it last" clause of FOSS development. I've done this exact thing multiple times, and the complaints always go away.
- asveikau 4y agoI don't get this cult of newness thing. To me there's no shame in a library being "done". If the maintainer abandoned it and it's working to your satisfaction in production, why not leave it alone? If it breaks you debug it yourself ... But if anything is sufficiently important, you'd probably still debug it yourself even if it were maintained.
- jjav 4y ago> I don't get this cult of newness thing. To me there's no shame in a library being "done". Exactly! There is nothing better than a library that's truly done. That's rare, sure, but it's the ideal state. All bugs are fixed, it does exactly what it set out to do and it is stable since it never needs to change again. If only all my dependencies could forever be libraries that are done!
- bhaak 4y agoIt's not about newness thing. It's about software bit rot. Every piece of software lives in an ecosystem. Libraries even more so. Unless the ecosystem is dead, there are always small changes over time until the code is outdated and should be replaced or redone. This has happened with lockfile. It has been superseded and shouldn't be used anymore. You say if it ain't broken don't fix it. That's only reasonable if you can say with 100% certainty that it won't break ever in the future. Otherwise you're building software debt.
- bigiain 4y agoI agree, but in my opinion you shouldn’t be downloading it from PyPI every time you use it in that case, or one day you’ll end up leftpad.js-ed or node-ipc-ed. It can be hard to work out when it’s the right time to commit a “done” version of a dependancy into your own repo, but the risks of not doing so are real and have bitten many people.