Kicking a dead horse: ugorji/go vs ugorji/go-codec

This was left unanswered in the prior closed issue, but is there some reason why you don't just keep the original repository name, and just add another repo as go-codec?

You can setup git to push to two different remotes at the same time so it really doesn't cost you anything (such as having to double-maintain), and since the repository name is optional (a user can choose to use the suggested name or the prior backwards-compat name), it really doesn't affect users/stale-projects and hence doesn't affect backwards compatibility during building in any way.

But this way at least people have an option to migrate to the new name over time. A number of your forks exist explicitly for renaming it to "go-codec" or "go-msgpack", so your users have definitely recognized that your initial project name "go" was a mistake. You could even point people to the https://gopkg.in url of your project in your docs to include the version as part of the package name.

This library is pretty much yours so you can do whatever you want with it of course, but there will definitely come a time when you will stop maintaining this project. And if this project follows the traditional open-source lifecycle, then someone else will likely inherit it. If somebody else implements a project called "go-codec" then they also have the option to impersonate your project. Before that happens, however, it'd be nice to get a solution for that the namespace collision available before that point happens I guess.

Anyways, it's all up to you of course. I just saw the comments/discussion that happened and don't think that aliasing the name of a project written in a relatively young language such as go is as intrusive as one might believe.

(edited to remove some unnecessary verbiage)

ugorji / go

Kicking a dead horse: ugorji/go vs ugorji/go-codec #275