Comment by peterfpf

10 years ago

I normally put a big "[DEPRECATED]" notice at the beginning of the README. This normally doesn't go unnoticed.

Another good example is harthur's "[UNMAINTAINED]" [1]

[1] https://github.com/harthur/brain

15 comments

peterfpf

Reply
progx  10 years ago

I watch the project and did not see "UNMAINTAINED", cause i scroll automatically on github projects down to the readme.

I search and then i see it in the title.

Better would be an Option in Github to set a project to unmaintained or deprecated, with an optional link to the new project (if some exist).

Github could then change the background color from white to an other color or add a border around the page, so that it is really obvious that this project es EOL.

technion  10 years ago

Have a look at the trending erlang repositories[0]. You will always find, near the top, basho/rebar. However, the subject on this reads:

    ATTENTION: Please find the canonical repository here:

The same advice is in the README.

What this tells you is that enough people are not only using this repository, which was last updated in August 2014 with a change to the README directing people at the new source, but people are giving it stars this week such that it shows up as "trending" higher than the correct repository.

There has to be something wrong with the deprecation process if this happens. [0]https://github.com/trending?l=erlang

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?".

  • clinta  10 years ago

    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.

    • simoncion  10 years ago

      > 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?

      5 replies →

    • kbart  10 years ago

      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.

      2 replies →