Add go.mod file, test on go1.11 in travis #206
Conversation
| module github.com/getsentry/raven-go | ||
|
|
||
| require ( | ||
| github.com/certifi/gocertifi v0.0.0-20180118203423-deb3ae2ef261 |
There was a problem hiding this comment.
I’m not too familiar yet with the new modules stuff, but is it possible to define this as a dependency without pinning it to any version? Ideally “certifi” is always latest and I’d hate for us to now lock in an old version with old certificates.
There was a problem hiding this comment.
Good question. At the moment this would indeed lock the version and from what I understand there is no way of specifying "latest", even when specifying a semver version (as the idea to look for the minimum compatible version).
In an ideal world the upstream repo would start tagging things, but then I'm still not sure what version would be downloaded.
I think it might be possible to simply omit the dependency, but then everyone has to pay attention not to commit the change that the go tool will apply everytime you do something with it.
Long story short, I will try to ask in the Gophers Slack to find out if there is a common approach to solving this yet and will let you know about what I find out.
P.S.: alternatively, the minimal version of making this a Go module would probably just be tagging master with v1.0.0 and not adding a go.mod file.
There was a problem hiding this comment.
I think even if certifi did start tagging, it’s always going to be a rolling window since you’d always want the latest version for security purposes. If you’re not aware, certifi project is just basically packaging up the latest bundle of trusted root certificates that make it easy to use on systems where you can’t trust the system certificates. So by nature, you kinda just always want the latest.
I think we’re at a point though where I am happy to pin the version for module compatibility. If that’s all that seems to be done, I will do that today.
Don’t go module tags need to explicitly be prefixed with a v? So I can’t tag simply 1.0.0, it has to be v1.0.0 correct?
There was a problem hiding this comment.
I also noticed that gocertifi does tag versions, they are calver schema, so 2018.01.18 is their latest tag. But I assume because this also is not prefixed with a v, so this does not work for Go module naming.
There was a problem hiding this comment.
Yes, the tag has to start with a v, so it needs to be v1.0.0.
Asking in the Gophers Slack made it very clear that you cannot specify "latest" as it's about reproducible builds and
For a package that gets updated four times a year it's not a big deal
to update the dependency manually.
I have to admit that seeing that both dependencies of raven-go are more or less stable (package errors will probably not introduce breaking changes anytime soon) I would currently tend towards omitting go.mod for the sake of having an up-to-date gocertifi and just tag master (i.e. close this PR), but I'll leave that decision up to you.
There was a problem hiding this comment.
Yeah, makes sense to me.
Let's go with just a tag for now, and leave out the go.{mod,sum} files since I agree that they don't make sense and the compatibility is low.
In light of this discussion, I've poked gocertifi to get updated and pushed them as well to adopt the v prefix for their tags.
|
Could we still start tagging |
Adds a
go.modfile to ease usage of the package as a Go module. In addition start testing on Go1.11 in CI.Ideally the latest revision on master would also be tagged as
v1.0.0now.