Consider copying go1 branch to v1

[lieut-data]

It's hard to use v1 of this repository with go modules:

package main

import "github.com/nicksnyder/go-i18n/i18n"

func main() {
	i18n.MustLoadTranslationFile("en.json")
}

> export GO111MODULE=on
> go mod init test
go: creating new go.mod: module test
> go run main.go
go: finding github.com/nicksnyder/go-i18n/i18n latest
build command-line-arguments: cannot load github.com/nicksnyder/go-i18n/i18n: cannot find module providing package github.com/nicksnyder/go-i18n/i18n

I believe this is a consequence of naming the v1 branch as go1 instead of v1. I can replace with a particular commit from that branch:

> go get github.com/nicksnyder/go-i18n/i18n@go1
go: finding github.com/nicksnyder/go-i18n/i18n go1
go: finding github.com/nicksnyder/go-i18n go1
> cat go.mod
module test

go 1.12

require github.com/nicksnyder/go-i18n v0.0.0-20190519163303-3c6ee9071cf0 // indirect

but this must be done by every client of my library that in turn uses go-i18n.

If I'm understanding the way go modules work, I /think/ it would suffice to create a second branch called v1 that is an exact copy of go1. Would you consider investigating that to support go modules users still reliant on this version of your library?

[nicksnyder]

Sorry about that, I do want v1 to be accessible via modules.

I did push go1 to v1 and tagged v1.10.1, but that doesn't seem to have fixed the issue.

It looks like go build is treating go-i18n as a repo which has not opted in to go modules and pulling the v2.0.3 instead of the v1.10.1 tag. I am somewhat stumped as to how to fix this. Any ideas?

[nicksnyder]

I suspect this might have been caused by #176 which I thought would be safe.

[nicksnyder]

I think the only way I can make this easier is to add back v1 to the master branch but I would prefer not to do this because it is confusing for new users to see both code versions.

This is similar to what the Kubernetes project does: kubernetes/client-go#551

It is unfortunate that this makes using v1 not work by default, and I wish there were a solution to it but I wasn't able to find one in my limited time searching (I would love to be proven wrong here).

I would recommend directly fetching the desired version like this go get github.com/nicksnyder/go-i18n/[email protected]

This must be done by every client of my library

Adding require github.com/nicksnyder/go-i18n v1.10.1 to the go.mod file of your library doesn't solve the problem?

[lieut-data]

Adding require github.com/nicksnyder/go-i18n v1.10.1 to the go.mod file of your library doesn't solve the problem?

Ah, yes, you're right. This does indeed solve my slice of the problem. Thank you!

I think the only way I can make this easier is to add back v1 to the master branch but I would prefer not to do this because it is confusing for new users to see both code versions.

Agree that avoiding confusion is a good reason, but I'm also wondering what happens if/when v3 is released. Another solution to the present and future problem might be to remove v2 and just lift that code to the root? I'm assuming that tags take over at that point exclusively.

[nicksnyder]

Ah, yes, you're right. This does indeed solve my slice of the problem. Thank you!

Great! I am going to close this issue then.

Another solution to the present and future problem might be to remove v2 and just lift that code to the root?

Yeah, I originally removed the v2 subfolder but that then breaks any projects that aren't using any dependency management at all (e.g. #184 (comment)) so I added it back.