readme: update badges

[casperdcl]

• travis badge seems to be hardcoded as green/ok (vis install: add snap option dvc.org#918 (comment))
• add other install methods (vis install: reorder methods and add badges #7495)
• ensure consistent style (flat, square, round)

[efiop]

travis badge seems to be hardcoded as green/ok (vis iterative/dvc.org#918 (comment))

It is meant that way. To not scare off people by failing build. We have another badge just beside that is dynamic and reflects build status on master.

[casperdcl]

It is meant that way. To not scare off people by failing build.

I'd argue that makes the badge pointless. Also it shouldn't really ever be the case that a tagged release build fails. On the rare instance that it does, it should be fixed very quickly.

[efiop]

@casperdcl AFAIK, travis only allows badges for branches and not for the latest release or tag, hence why we have that dummy badge plus a real one for master

[dmpetrov]

I guess, the common approach is to have prod branch and release only from this branch. So, the badge will be green 99.99%.

But it seems like a bit heavy solution. Are there any other reasons to have a separate branch? 😀

[casperdcl]

Hmm I feel like what this needs is a PR on shields.io to automatically pick up the last Travis tagged build. Or Travis CI itself could provide that badge. In the meantime I think just a badge for master should be enough. Normally master should never fail to build either since we should test things in dev branches before merging...

We can always set the description of the master badge to be "development," "edge," or similar so it doesn't look like releases are broken when master is.

[efiop]

dev branch complicates the workflow, we've considered this awhile ago. So far there is no real need in it and a badge is hardly a reason. Current dummy badge is hackish, but it serves the purpose. Hence why I don't think we should bother messing around with it for now.