2 ms·
> in 15 years, nobody looked at the release notes and thought to make a change? What change could have been made? Package managers can't "just" remove it as th
by arp242 3y ago
> in 15 years, nobody looked at the release notes and thought to make a change?
What change could have been made? Package managers can't "just" remove it as that would break people's scripts, and adding their own warning message leaves us where we are now. I suppose a package-message could be added, but I don't think anyone expected that [ef]grep would start printing warning messages all of the sudden – lots of things are "deprecated" but still work and will likely continue to work for decades to come – so why bother?
- cratermoon 3y agoWhy bother deprecating things if they aren’t ever going to be removed? With deprecate and remove them after a reasonable time or don’t bother.
- arp242 3y agoYou can discourage people from using it while still maintaining compatibility. I have a Go library with some functions that have been deprecated since Go 1.1 (2013); they're just some aliases or wrappers for the newer symbols. They will stay there forever until I have enough reason to release a v2 (which may be never). POSIX also includes plenty of legacy/deprecated stuff like mktemp() that will likely never be removed. A CLI is a public interface; breaking compatibility is kinda bad.
- JdeBP 3y agoThe complainant who set this off (by filing a GNU bug report) said the same. Ironically, several people missed that one of xyr acceptable outcomes was just removing the claim about deprecation from the manual page.