Add SemVer stability badge to README

First of all, thanks for Requests!

Would you be up for adding a badge that shows how SemVer compliant / bug free new releases are? I was looking through the data we gather at Dependabot and realised we could put one together, so threw together the below:

[![SemVer](https://api.dependabot.com/badges/compatibility_score?dependency-name=requests&package-manager=pip&version-scheme=semver)](https://dependabot.com/compatibility-score.html?dependency-name=requests&package-manager=pip&version-scheme=semver)

If you click through then there's a description of how it's calculated - basically it takes all of the relevant updates Dependabot has done for projects that use Requests and checks what percentage of the time specs pass on the upgrade PR.

The score is slightly lower than 100% because some projects have flaky specs, but I'm working on filtering them out from the data, too :octocat:.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4707?src=pr&el=h1) Report
> Merging [#4707](https://codecov.io/gh/requests/requests/pull/4707?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/cd97ce90ba04156a4aae2fd05aa22c790bec1a5c?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4707/graphs/tree.svg?width=650&src=pr&token=mZGswIiXLa&height=150)](https://codecov.io/gh/requests/requests/pull/4707?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4707   +/-   ##
=======================================
  Coverage   66.79%   66.79%           
=======================================
  Files          15       15           
  Lines        1563     1563           
=======================================
  Hits         1044     1044           
  Misses        519      519
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4707?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4707?src=pr&el=footer). Last update [cd97ce9...790e244](https://codecov.io/gh/requests/requests/pull/4707?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Hi there @greysteil 

I'm not sure I fully understand the value of this badge. Could you share more what people should understand when they see this?

As it stands, I'm not familiar with dependabot and since it's not a service the project uses, I'm not sure if we should be including it.

@sigmavirus24 - of course.

The idea is to show users how stable / bug-free new releases are. Dependabot creates update PRs for lots of Requests users (you can see them [here](https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+requests+in%3Atitle)), and we can use the data on whether their CI passes on the PR base and head branches to check whether new versions of Requests are backwards compatible and/or bug-free.

The information is hopefully useful for a couple of reasons:
1) It's obviously a good thing to aim for for new releases to be bug free and backwards compatible if they're non-major. Measuring what happens when users update is a good way to check it.
2) With Pipenv it's possible (and sensible) to specify [compatible release requirements](https://www.python.org/dev/peps/pep-0440/#compatible-release), but you probably want to know what the backwards compatibility strategy of the library is before doing so. Having a badge showing that compatibility strategy is SemVer, and that it's stuck to, lets users specify better requirements.

Shouldn't matter at all that Requests doesn't use Dependabot itself - it's just the data source. 🙂 

Interesting. That data sounds helpful. I'm wondering if you can share what aggregation and tracking you perform on your API endpoint.

Our downstream redistributors will care about this and any security minded users will ask this as well. Keep in mind, most of them will attempt to discover it themselves and will tell us, very rudely, if you're tracking anything.

Further more, it sounds like Dependabot is a company that could easily disappear tomorrow (as most start-ups and companies are want to do). To indicate SemVer (which isn't strictly correct anyway), we could just as easily use a shields.io badge and I'm sure most dependabot users can look up the stability of Requests on your website.

All of this is to say that I'm leaning against adding the badge for my own future peace of mind.

@sigmavirus24 - sorry, it sounds like I've not been clear about where the data is coming from. No data comes from badge endpoint itself. When people sign up for Dependabot they give us permission to create pull requests for them and to monitor the status of those pull requests - that's where we get the data from. Looking at the badge on Request's readme, or clicking through to it to get a description of what it means, doesn't produce any data that we're interested in (although to fully answer your question, we do have Google Analytics on the show view that the badge links to).

I've not heard anyone complain that this in unclear, and the badge is included on several high-profile repos for other languages (webpack, sinatra, jest, rubocop). Hopefully it's clearly explained by the first paragraph if you click on the badge?

> Dependabot has updated requests between SemVer compatible versions 121 times across 70 projects so far. 98% of those updates passed CI.

On our backend we're using shields.io to generate the badges, and then caching them for a week to reduce load on their servers. That said, we're planning to move the URLs to be shields.io ones as soon as they're able to deploy again (the PR to add Dependabot to shields.io is [merged here](https://github.com/badges/shields/pull/1734). Unfortunately their resources are limited and they've been unable to deploy for the last few months.)

Finally, on Dependabot disappearing, we're a bootstrapped, profitable company, but I can of course understand your concern. The worst thing that would happen if we did, however, would that this badge stopped working and that I or some other contributor put in a PR to remove it. Hopefully that's not too serious a worry.

Would you be happier with this badge if the link was a shields.io one? I can understand the concern that introducing an image from a foreign source to your README might allow us to be doing some nefarious tracking of your README views that using the shields.io link, when deployed, would fix.

Hi @greysteil, thanks for reaching out about this and the detailed responses. I took a look over Dependabot but wasn't able to find much beyond the number of passing/failing builds. It doesn't look like information about the failures are included, so it's hard to determine *why* a project may not be SemVer compliant. The current data seems to be measuring the robustness of users build pipelines rather than the backwards compatibility of a project, which may be misleading or abusable.

I think I'm leaning against adding this for now unless @sigmavirus24 sees benefit I'm missing. Perhaps we can revisit as the project evolves.

👍 - the next thing I'm planning to add to the view is a way to see the PRs on which the update has broken CI. I'll put in a new PR then. Also planning to add a way for it to be used for beta releases (where Dependabot won't generate PRs for users, but will generate a commit on a new branch and check their CI) - so you'd be able to see whether a pre-release is breaking anyone's tests before releasing a new version.