samalba
Version to Avoid Breaking API Changes
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.
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.
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?
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.
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 https://github.com/samalba/dockerclient/issues/40#issuecomment-63335256.
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.
This is getting a bit out of hand. I've forked this until versioning is implemented or the API stabilizes.
+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.
