On Fri, Jun 12, 2015 at 5:02 PM, Michael Stapelberg <stapelb...@debian.org> wrote: > The Debian policy is to not ship copies of libraries in packages. For C, > that works quite well, since library authors are generally aware of SONAMEs > and when they need to bump them. For Go, package paths are supposed to never > break backwards compatibility, and it seems like most of the community > agrees. We haven’t had a single case of backwards compatibility breakage yet > (that I know of).
I agree it's the convention to never break backwards compatibility, but it does happen from time to time. I will sheepishly raise my hand and say that I've done it, and will probably do it again, for code that I own where other code I own is the primary or sole user. In such a case, would bumping a major semantic version number (in the form of a git tag) help you? I guess this would be the analog of C library versions, but I don't actually know how Debian deals with the problem of dependent A needing version 1 and dependent B needing version 2, even for C libraries. On Mon, Jun 15, 2015 at 7:13 AM, Michael Stapelberg <stapelb...@debian.org> > golang-github-jacobsa-oglematchers is in Debian > golang-github-jacobsa-reqtrace is in Debian > golang-goprotobuf was updated in Debian > > golang-github-jacobsa-oglemock is in the NEW queue > golang-github-jacobsa-ogletest is in the NEW queue > golang-google-appengine is in the NEW queue > golang-golang-x-oauth2 is in the NEW queue Great! Thank you. :-) > Looking at remaining dependencies, you could save me a lot of headaches if > you could split out github.com/googlecloudplatform/gcsfuse/timeutil into a > separate repository. Otherwise, we have circular dependencies > (github.com/googlecloudplatform/gcsfuse depends on github.com/jacobsa/fuse, > which depends on github.com/googlecloudplatform/gcsfuse/timeutil). > > Also, either doing the same with github.com/jacobsa/gcloud/syncutil or > inlining the (github.com/jacobsa/fuse/fsutil).AnonymousFile call in > github.com/jacobsa/gcloud/gcs/tools/gcsthroughput/gcsthroughput.go would > help as well. I had been feeling guilty I hadn't done this anyway; thanks for the push. Done: https://github.com/jacobsa/timeutil https://github.com/jacobsa/syncutil _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers