Nathan Youngman

Though gopkg.in can still be applicable when using the vendor support that Go 1.6 is helping enable, I personally don't see myself using gopkg.in in the future (eg. https://github.com/go-fsnotify/fsnotify/issues/108). That...

If supporting multiple users, it could just be the default behaviour, which amounts to using gopkg.in as is on a different domain. If I were using this, it would be...

I like @slimsag's [suggestion](https://github.com/azul3d/issues/issues/25#issuecomment-56276582) of making gopkg into a pkg where things like the GoPkg.in homepage are part of the cmd. That would provide a lot of flexibility. Stripe provides...

I haven't tried gopkg.in with subpackages yet. Do you have a v1 branch with different import paths? And on every release you merge changes from master and have to update...

> I understand we could switch the major version anytime breaking changes are introduced but having a library of version v13.1.5 which is not production ready is funny. That seems...

@fervic See #18 regarding a badge.

https://github.com/azul3d/semver is a fork/rewrite for self-hosted use. Might do the trick.

That looks like the old-style urls. I'm not sure if they are still supported? gopkg.in/yaml.v2 is equivalent, if you can update it.

If this happened recently, I can't imagine it being an intentional change.

I'm not sure if this should go in our README. Probably would be better as a separate blog post at https://nathany.com/.