{"action":"created","issue":{"url":"https://api.github.com/repos/google/go-github/issues/376","repository_url":"https://api.github.com/repos/google/go-github","labels_url":"https://api.github.com/repos/google/go-github/issues/376/labels{/name}","comments_url":"https://api.github.com/repos/google/go-github/issues/376/comments","events_url":"https://api.github.com/repos/google/go-github/issues/376/events","html_url":"https://github.com/google/go-github/issues/376","id":160958962,"number":376,"title":"versioning and tagging releases","user":{"login":"willnorris","id":1112,"avatar_url":"https://avatars.githubusercontent.com/u/1112?v=3","gravatar_id":"","url":"https://api.github.com/users/willnorris","html_url":"https://github.com/willnorris","followers_url":"https://api.github.com/users/willnorris/followers","following_url":"https://api.github.com/users/willnorris/following{/other_user}","gists_url":"https://api.github.com/users/willnorris/gists{/gist_id}","starred_url":"https://api.github.com/users/willnorris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/willnorris/subscriptions","organizations_url":"https://api.github.com/users/willnorris/orgs","repos_url":"https://api.github.com/users/willnorris/repos","events_url":"https://api.github.com/users/willnorris/events{/privacy}","received_events_url":"https://api.github.com/users/willnorris/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2016-06-17T19:29:34Z","updated_at":"2016-06-17T20:34:51Z","closed_at":null,"body":"We generally try not to have egregious breaking changes in this library, but we're also not afraid to do them when necessary (the latest example being #375).  We've gotten a couple of people asking for us to use semver on google/go-querystring#11, which we could also consider doing here.\r\n\r\nThat doesn't help us for #375, but would allow us to do future breaking changes at a version boundary.  I have no intention of changing the import path to use gopkg.in or anything like it, but it would still help set appropriate expectations for folks when they do upgrade to a new version.  And keeping a `CHANGELOG.md` file might be nice (although a bit of work to keep up to date) to point out new APIs that we support, etc.\r\n\r\n@gmlewis @shurcooL what do you think?"},"comment":{"url":"https://api.github.com/repos/google/go-github/issues/comments/226874882","html_url":"https://github.com/google/go-github/issues/376#issuecomment-226874882","issue_url":"https://api.github.com/repos/google/go-github/issues/376","id":226874882,"user":{"login":"willnorris","id":1112,"avatar_url":"https://avatars.githubusercontent.com/u/1112?v=3","gravatar_id":"","url":"https://api.github.com/users/willnorris","html_url":"https://github.com/willnorris","followers_url":"https://api.github.com/users/willnorris/followers","following_url":"https://api.github.com/users/willnorris/following{/other_user}","gists_url":"https://api.github.com/users/willnorris/gists{/gist_id}","starred_url":"https://api.github.com/users/willnorris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/willnorris/subscriptions","organizations_url":"https://api.github.com/users/willnorris/orgs","repos_url":"https://api.github.com/users/willnorris/repos","events_url":"https://api.github.com/users/willnorris/events{/privacy}","received_events_url":"https://api.github.com/users/willnorris/received_events","type":"User","site_admin":false},"created_at":"2016-06-17T20:34:51Z","updated_at":"2016-06-17T20:34:51Z","body":"> Moving the canonical source to gopkg.in is, in itself, a breaking change, right?\r\n\r\nIn case you misread, I have **zero** intention of moving to gopkg.in.  It think it's a clever service and I greatly respect Gustavo, but I'm not about to add an extra single point of failure that I have no control over to how people access this package if I don't have to.  And I definitely don't want to cede control of the namespace; I actually don't even like \"github.com\" in the import path either (as you know from my personal packages), but I don't have a good Google controlled hostname that would work well for this.  And as you point out, vendoring mostly obviates the need for a service like gopkg.in.\r\n\r\nAll that said, there are still other advantages to versioning and tagging the library, some hypothetical/theoretical, some practical.  \r\n - A tagged release my carry with it some extra assurance of stability or having been more thoroughly tested (for example, running go 1.6.x versus tip).  That's not really an issue with go-github, since we tend to keep master well tested.\r\n - As pointed out in https://github.com/google/go-querystring/issues/11#issuecomment-226850306, glide supports semver similar to Gemfiles where you can specify a major version you want and it will always grab the latest within that range.\r\n - Even if you're not using glide (or any other vendoring tool for that matter), sticking to semver sends a signal as to what users of the library can expect (in terms of compatibility) from a given release.\r\n\r\nNow even with that said, I don't typically version my go libraries because I always vendor anyway, and versioning is not all that common in the go community.  And I don't relish the idea of trying to keep a changelog up to date, making decisions about version numbers, etc."}}
{"actor":{"display_login":"willnorris"}}