please tag new release

[onlyjob]

Kubernetes already bundles unreleased snapshot of lumberjack.v2...

[natefinch]

There's really no releases in Go.... I made a release of lumberjack.v1 just to try it out, but it doesn't really buy anyone anything. The HEAD of the v2 branch (as accessed by gopkg.in/natefinch/lumberjack.v2) is the v2 release. Any updates to that will be minor patches. If I ever need to do any kind of backwards incompatible work, I'll make a v3.

[onlyjob]

There's really no releases in Go....

Yes there are. :) You can find examples in projects of CoreOS and Docker.

Versioning provides additional benefits to encourage vendoring of a particular (e.g. latest stable) release contrary to random unreleased snapshots.

Versioning provides safety margin for situations like "ops, we've made a mistake but reverted problematic commit in master". Presumably tagged version/release is better tested/reviewed than random snapshot of "master" branch.

Tags/releases are useful for downstream package maintainers (in Debian and other distributions) to export source tarballs, automatically track new releases and to declare dependencies between packages. Read more in the Debian Upstream Guide.

See also

• https://en.wikipedia.org/wiki/Software_versioning
• http://semver.org/

Thank you.

[natefinch]

CoreOS and Docker are applications, not Go libraries. That's a completely different beast.

There are no random, unreleased snapshots in this repository. I do not do development on master. The only changes in master are thoroughly tested and reviewed. Any time you pull head of master of this repo, it is guaranteed to be backward compatible with whatever code was previously using it, and is guaranteed to be stable.

As for Debian etc... they should be concerned with versions of applications, not code that is statically compiled inside that application. Worrying about compatibility of my library is for application authors, not OS maintainers. And yes, I know (more or less) how Debian packaging works.... and I disagree quite strongly with their approach. I trust Docker to build Docker, not Debian.

[natefinch]

Which is not to say that I'm totally against version numbers... at some point I may release 2.1 if I add a new feature... but I don't see the point in marking every new commit as 2.0.N. Me marking it as 2.0.5 doesn't make it any more or less likely to break.

[onlyjob]

CoreOS and Docker are applications, not Go libraries

I've mentioned projects of CoreOS and Docker. Both projects maintain many properly versioned libraries.

Nate, your vision on vendoring is astoundingly incorrect.

In Debian instead of vendoring (which IMHO should be condemned as it throws away 20+ years of best practice in software engineering) we have to reuse standalone packages. Packaging makes a lot of sense because it reduces duplication and allows to run tests properly on build -- a something often neglected for vendored libraries.

You are not considering context. For isolated application vendoring may be a "sensible solution" even when developer dumps random snapshot of a library to source tree and never update it or track upstream changes until things break.

In GNU/Linux distributions like Debian shipping coherent collection of software the only sensible way is to reuse dependency libraries. Think about harms of static linking: if you have 20+ applications "vendoring" different revisions of (for example) libjpeg library how are you going to patch vulnerability in the latter? Backport (isolate) fix, re-vendor and try to re-build all applications? (Or maybe re-vendor latest version of the library and hope that all applications compile?) How much effort is that going to be and how long it is going to take? Also, how many revisions of library you can effectively support?

I hope that makes sense and thanks for considering versioning of lumberjack.

[natefinch]

For isolated application vendoring may be a "sensible solution" even when developer dumps random snapshot of a library to source tree and never update it or track upstream changes until things break.

Aren't you also just randomly dumping a snapshot of a library into debian's packaging system? Except that instead of it being the version that the application authors are expecting and have tested against, it's some random other version they may never have looked at.

Why do you think you'll be better able to test my package against 20+ applications that use it, versus the people who actually write that code? Why do you think you'll be more likely to stay on top of keeping dependencies up to date across all 20+ of those applications, but the entire development team on each of those projects won't be able to keep their one project up to date?

Think about harms of static linking: if you have 20+ applications "vendoring" different revisions of (for example) libjpeg library how are you going to patch vulnerability in the latter? Backport (isolate) fix, re-vendor and try to re-build all applications? (Or maybe re-vendor latest version of the library and hope that all applications compile?) How much effort is that going to be and how long it is going to take?

You just described exactly why dynamic linking is such a bad idea. How can you possibly know that those 20+ applications will work with the new version of the library? The fact that they can all use the version that they know works and have tested is amazingly awesome for the application authors. No more dependency hell.

And yes, that might mean that some of them are vulnerable if a security bug is found. They'll need to update their code to work with the fixed library, rerun their tests, their CI, etc. That's the job of the application development team. And if they won't update their software in a timely fashion when a security bug comes up, maybe they shouldn't be distributed by Debian.

Also, how many revisions of library you can effectively support?

I only have to support one. If Kubernetes or someone else comes to me with a problem, and they're not on HEAD of master, I first ask them to update to head of master. If they still have a problem, then we can talk. By tagging multiple releases, I would actually be making this much worse. I now have explicitly said that multiple points of my library are stable and ok to use, and the onus is on me to support each of them.

I'm sorry that the Go ecosystem doesn't work the way you would like it to.

[onlyjob]

Aren't you also just randomly dumping a snapshot of a library into debian's packaging system?

No, we are always trying to introduce only stable releases, whenever possible.

Except that instead of it being the version that the application authors are expecting and have tested against, it's some random other version they may never have looked at.

True, but when same version of library is tested against many applications there is greater degree of confidence.

Why do you think you'll be better able to test my package against 20+ applications that use it, versus the people who actually write that code?

Because we have QA and CI. Because we build for more hardware architectures than you do. Because we have users who actually use your code. Because we run tests for your library, unlike those who bundle (i.e. "vendor") it.

Why do you think you'll be more likely to stay on top of keeping dependencies up to date across all 20+ of those applications, but the entire development team on each of those projects won't be able to keep their one project up to date?

There is strong evidence showing how little care developers usually dedicate to bundled/vendored libraries. Typically they won't even update it until things break. You can see vendored library as needless forking and forking is harmful.

Sharing and reusing common libraries promote communication between maintainers and helps to maintain a healthy ecosystem.

You just described exactly why dynamic linking is such a bad idea. How can you possibly know that those 20+ applications will work with the new version of the library?

Really?

The fact that they can all use the version that they know works and have tested is amazingly awesome for the application authors. No more dependency hell.

You just want to isolate yourself in your little corner and don't communicate with library developers. How convenient it is to say "I'm not troubling myself with library transition as I've already vendored working old version". That is what more likely to happen.

And yes, that might mean that some of them are vulnerable if a security bug is found. They'll need to update their code to work with the fixed library, rerun their tests, their CI, etc. That's the job of the application development team.

Think about duplication of effort. There is one problem to fix in one library contrary to fixing the same problem many times as you suggest.

And if they won't update their software in a timely fashion when a security bug comes up, maybe they shouldn't be distributed by Debian.

Agreed. But how do they track changes in dependency libraries? Usually they just don't. That's where GNU/Linux distribution' add significant value due to work of their security team.

I only have to support one.

Same here! We need to support only one reusable shared library.

It is funny you've mentioned Kubernetes. In Kubernetes I've seen situation when it links statically to multiple different versions of a library through its dependencies. Suppose K depends on libraries A and B where A vendoring C-1.1 and B depends on C-1.5. Both versions of C are then compiled into K. This is the mess Kubernetes authors produce. :( :(

If Kubernetes or someone else comes to me with a problem, and they're not on HEAD of master, I first ask them to update to head of master. If they still have a problem, then we can talk.

There are chances they come to you when we (Debian maintainers) ask them to update your library because we care about healthy relationships and they have little incentive to do so.

By tagging multiple releases, I would actually be making this much worse. I now have explicitly said that multiple points of my library are stable and ok to use, and the onus is on me to support each of them.

No, you'll still support only the latest tagged release, like many other developers do except that it will be more convenient to notice new releases and vendor by tags.

I'm sorry that the Go ecosystem doesn't work the way you would like it to.

Golang ecosystem is too young and should learn a lot before it matures.

[natefinch]

I'm sorry that we disagree on this point. I know you're trying to do what you believe is best. I have to do what I believe is best, too.

If I mark something other than HEAD of my repo as a released version, people looking at the repo will have to wonder if HEAD is unstable. People using go get will always get HEAD, so they'll worry they're getting unstable code (even though they're not).

The other option is that I mark every new commit to master as a new patch version, and that's kind of a pain in the butt, and doesn't really help anyone except distro maintainers doing things that I disapprove of.

So, my answer is no, I'm not going to tag a release version. I'm sorry if this makes your life more difficult.

[onlyjob]

Fair enough, thanks for considering. Versioning would make little sense if you always aim to keep HEAD of master stable and regression free...