add vcs-type parameter and change to v1.1 API

[tylux]

Version Control System (:vcs-type)

New with v1.1 of the api, for endpoints under /project you will now need to tell CircleCI what version control system type your project uses. Current choices are ‘github’ or ‘bitbucket’.

[jszwedko]

👍 thanks for starting this discussion @tylux

My main hesitation with this is that it is a breaking change to API. I'll think about it a bit more, but I'm curious if there are any clever ways we could keep the current API and also add support for v1.1 absent maintaining separate branches.

The right answer may also be to just flip the switch and force people to upgrade as you've done here.

I'm not sure why CI didn't run on this PR, but the tests will need to be updated too.

[kudrykv]

@jszwedko you can use gopkg.in to version library.
Simply create a branch named e.g. v2, then gopkg.in/jszwedko/go-circleci.v2 will point to your repo to the v2 branch.
Then, one can pull that by go get gopkg.in/jszwedko/go-circleci.v2.

[martinssipenko]

@jszwedko Any updates on this matter?

[tgermain]

I think your modifications break the tests @tylux
You may find a fix here

[phamdt]

also interested in this PR

[jszwedko]

Apologies for falling off on this one. I think v1.1 of Circle's API has been around long enough that we could make it the default, but I'd still like to provide an easy way for projects depending on the old API to continue using the client (i.e. minimize the amount of changes they'd need to make to continue relying on the library).

I think this could be possible by moving master to a v1 branch that will only get bug fixes, create a v1.1 branch pinned to v1.1 of the CircleCI API that people can pin their projects to, and have master track the latest API version.

I'll try to follow up on this soon. I think it's also an opportunity to see if we can make other backwards incompatible improvements to the API of this library.