Formatting versions

[op]

Formatting versions

[jbenet]

Those are go vet errors, by the way.

[nwolff]

+1. I have configured go vet errors to fail my automated builds, and these false positives don't help.

[op]

Is there a way to instruct go vet to not report these errors? I've decided to not break backwards compatibility.

At the same time I've been thinking of moving this project to eg. github.com/go-logging/log, break backwards compatibility there, remove and clean it up a bit and have it in "experimental" state for a while. Right now I don't have time to do this. Any thoughts?

[nwolff]

Another option is to introduce semantic versions maybe with something like http://labix.org/gopkg.in

I've never done it but I use this library that uses it: https://github.com/alecthomas/kingpin

I guess it would mean creating a new branch and pointing "gopkg.in/op/go-logging.v2" to it.

[giftig]

Incidentally I use goyaml via gopkg.in, and it seems like a pretty neat solution.

[optimality]

What about (for example) just introducing Errorf as an alias for Error? That would enable us to use Errorf to avoid go vet noise without breaking backwards compatibility.

[nwolff]

@optimality it looks like an ok short-term solution if @op does not want to create a v2

The main remaining problem would be that some non-f methods such as Error expect a format, while others such as Panic don't, making things somewhat confusing.

[optimality]

@op Have you reached a decision on this?

[gdm85]

Sorry, but if go vet reports an error by default with this, I'd prefer to stick to go vet and fork/fix the bug.

[gdm85]

Right now I am using this syntax to workaround the problem:

go tool vet -printf=false src/

It would be best if I could get rid of this incomplete and error-prone workaround...

[op]

This is fixed now.