Version to Avoid Breaking API Changes

[rynbrd]

Lately there have been a number of changes which have broken this library's API. This has affected my project, Beacon, and its users. Short of compiling my own project on a daily basis there's no way to get notified when changes occur.

I'm proposing that semantic versioning be implemented and a service such as gopkg.in be used so that API changes do not break existing packages.

Thanks.

[rynbrd]

Also, I am aware that vendoring or forking dockerclient would solve my problem. While I am not entirely averse to doing this as a last resort I would like to avoid it if at all possible.

[samalba]

The lib is still in super active development. Hence the regular breaks. I think it's the right time to version it. How would you handle the versions?

[rynbrd]

I'd use semantic versioning while following gopkg.in's conventions. That way your version numbers track API changes separately from bug fixes and feature additions.

[ehazlett]

Doesn't that force people to use gopkg.in? Not necessarily a bad thing,
just wondering.

On Mon, Nov 17, 2014 at 11:51 AM, Ryan Bourgeois [email protected]
wrote:

I'd use semantic versioning http://semver.org/ while following
gopkg.in's http://gopkg.in conventions. That way your version numbers
track API changes separately from bug fixes and feature additions.

—
Reply to this email directly or view it on GitHub
#40 (comment).

[rynbrd]

Only if they wish to version the dependency. There's nothing preventing them from tracking master by pointing at github.com/samalba/dockerclient, vendoring the library, or using a different service like gopkg.cc or gopin.org.

[rynbrd]

This is getting a bit out of hand. I've forked this until versioning is implemented or the API stabilizes.

[byxorna]

+1 for creating a 0.1.0 release that people can target. Alternatively, @bluedragonx you can just use godep and lock your app to use a specific commit to insulate yourself from changes.