Closed creachadair closed 5 years ago
Ping @adjackura, does this seem like a reasonable change?
With go 1.12 I don't think go.mod is a strict requirement. I'll tag with release 1.0.0 so this library can be used in modules though. With the release of 1.13 I plan on going through and making all my repos module based, but that's 6 months away.
With go 1.12 I don't think go.mod is a strict requirement. I'll tag with release 1.0.0 so this library can be used in modules though. With the release of 1.13 I plan on going through and making all my repos module based, but that's 6 months away.
Even if go.mod
isn't required for 1.12, it would be helpful for people using 1.11. I proposed this addition because kythe.io is currently using this package, and would like to stop pinning to a fixed commit hash. Since we aim to have our tools build with modules as well, this would help (and seems low-cost).
Thank you! Would you be willing to tag v1.0.1 to include this commit?
In order to work well with Go modules, this package should have a
go.mod
file and semantic version tags on release versions. I have provided a rudimentarygo.mod
file here, and if you are willing to alsogit tag v0.0.1 HEAD
that would start the release history.If the API of the package is considered stable, you could instead use
v1.0.0
, but at that point module users will expect breaking changes to increment the major version. I don't have a clear sense of how much this package is maintained, sov0
would be a safe default for now.