Closed belak closed 6 years ago
Is there a reason you chose not to define the v2 series as module gopkg.in/irc.v2
?
This has been fixed by defining the package as gopkg.in/irc.v3
. I was trying to avoid using that because it's always seemed a bit silly to me that go modules break the concept that a module is a folder in a repository but I think there's no avoiding it now.
Previously, this package was importable as gopkg.in/irc.v2 if you wanted a stable version and github.com/go-irc/irc if you wanted to always track the HEAD of master but I don't think there's a way to do that with modules
Anyway, in short, I updated the module to gopkg.in/irc.v3 and retagged v3.0.0 so it points to the proper module.
The main reason for this is that I strongly dislike importing this package as github.com/go-irc/irc/v2 and would like most of my tooling to recognize the import name properly. Additionally, I don't think this library is (currently) important enough for this to cause an issue in any packages other than mine. If you import from github.com/go-irc/irc this package will continue to work and as go module support is experimental, I don't have many qualms about temporarily breaking support.
Alternatively, if I could keep the current version tags and import this as github.com/go-irc/irc, that would be fine.
Related to #68. I plan on re-working tags and changing the module to the base path. As this library is not 100% stable, I plan on remapping the tags as follows:
Here are the current tags, for reference: