Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2: decide on import path and make a new release #587

kolyshkin opened this issue Mar 24, 2020 · 3 comments

v2: decide on import path and make a new release #587

kolyshkin opened this issue Mar 24, 2020 · 3 comments


Copy link

@kolyshkin kolyshkin commented Mar 24, 2020

The latest release is from September 2018, maybe it's time to make a new one?

The primary reasons for a new release are #509 and #515; this will make the package not depend on any other packages. Including #586 would be nice, too.

@kolyshkin kolyshkin changed the title Tag a release Please make a release Mar 24, 2020
@dmitshur dmitshur added the v2 label Mar 24, 2020
@dmitshur dmitshur changed the title Please make a release v2: make a new release Mar 24, 2020

This comment has been minimized.

Copy link

@dmitshur dmitshur commented Mar 24, 2020

This should be done.

In order to be able to publish new v2 versions, a blocking task is to resolve the current lack of clarity about what import path should be suggested and continued to be used for v2: or The go.mod file says one thing, the README on master branch says something that isn't very consistent.

By making a newer release, some decision would be committed to, and ideally that decision should be a good one given the constraints this project is currently operating with. Some of the decisions made in the past predate a good understanding of modules and best practices regarding v2 versions, which has made this decision more difficult to make conclusively.

I suspect that in the current situation, the best course of action is to continue to use the import path, as defined by the module statement in go.mod file in v2 branch:


I started talking to @rtfb about resolving this situation a number of months ago, but then unfortunately dropped the ball on it due to lack of bandwidth. But I wanted to post this comment to shed light on what I believe is a large contributing factor to no new v2 releases.

@dmitshur dmitshur changed the title v2: make a new release v2: decide on import path and make a new release Mar 24, 2020

This comment has been minimized.

Copy link

@russross russross commented Mar 25, 2020

I'm happy with either import path and agree that we should post a new release soon. I haven't been following developments in the module system very closely--is there one approach that is more forward looking/will fit in better with the community than the other?


This comment has been minimized.

Copy link

@SamWhited SamWhited commented Mar 25, 2020

There's also a third option which I always personally prefer: using a new vanity import path (eg.

This requires that someone own a domain name and setup an HTTP server (or use a service like Netlify or GitHub Pages) which is more work for the maintainers, however, it gives you the benefit of owning your package import instead of relying on GitHub or never changing or going under or being changed to or similar. While this may not seem likely, other scenarios could be imagined where GitHub becomes impractical in the future, for example a price change, adding more extreme rate limiting that causes fetching packages to break more often, the author just decides they don't like GitHub and want to use , etc.
Using a vanity import keeps things flexible in the future, and avoids unforeseen future issues at the cost of a tiny bit of infrastructure work. I would be willing to help set this up if you want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.