Comment by simoncion
10 years ago
> I normally put a big "[DEPRECATED]" notice at the beginning of the README.
Aye. Some folks in the discussion linked to by krschultz complain that "People sometimes don't read the README and -thus- don't notice deprecation warnings.". To them I ask: "What makes you think that those sorts of people will notice anything less than an overlay that prevents them from interacting with the Github UI for that particular repo?".
One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.
> One concern would be around tools that fetch from github automatically.
Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right?
> ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings]
I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?
Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches https://example.org/pkg/foo?go-get=1. So coordination between go and github could implement something for deprecated repositories without changing anything in git.
More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths
1 reply →
I am not your grand parent poster but I fully agree with you and I'd go further than that.
The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Facebook/Uber.
2 replies →
Agree. I've had literary thousands of libs/tools/apps dependencies in one of my projects that was built using automatic tools (Bitbake + Yocto). It's simply impractical to go through all these README's manually, so a tool to detect depreciated projects is a must in such situations. Of course, one could implement some tool to scan all README files for keywords ('DEPRECIATED', 'UNMAINTAINABLE' etc.), but that's just a workaround and I'd like a proper, reliable way to do that.
What if the maintainer never marks the library as deprecated? What if they're just hit by a bus?
I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many. Whoever decided it was OK to depend on that library should be able to follow it closely enough to say when it cannot be depended on.
1 reply →