search

nicksnyder / go-i18n

Translate your Go program into multiple languages.
MIT License
3.03k stars 277 forks source link

V2 is removed #319

Closed jerome-laforge closed 10 months ago

jerome-laforge commented 10 months ago

With https://github.com/nicksnyder/go-i18n/pull/318 & https://github.com/nicksnyder/go-i18n/commit/f0cd8fa6f1eef53b5851f290e1240d7700856095, did you expect that V2 becomes V1? If it is true, it is not conform with semver and it is a big breaking change.

nicksnyder commented 10 months ago

Can you explain to me what broke for you? I have not tagged a release that includes #318 yet.

Here are some details that would be helpful:

I suspect what might have actually broken you is that I deleted the go1 branch because I thought it wasn't necessary anymore but it might still be so I just recreated it. Are you still having an issue?

nohajc commented 10 months ago

Maybe the concern is whether the library can still be imported with the /v2 suffix even though it doesn't correspond to a real directory in the repo.

jerome-laforge commented 10 months ago

Hello, Thank for your support.

It sounds like you are depending on v1 of the library and not v2, is that correct?

Correct

Are you using a tool like Go modules to version your dependencies?

Yes, Go modules

What version of Go are you using?

Go 1.21

I suspect what might have actually broken you is that I deleted the go1 branch because I thought it wasn't necessary anymore but it might still be so I just recreated it. Are you still having an issue?

Currently, I have no problem. But if you remove v1 or if you plan to release a new version of v1 (for example with v1.11) with the v2. It will break all my code since v2 is not compatible with v1 (v1.10 and before).

nicksnyder commented 10 months ago

v1 was removed from the main branch in 2019 so changes on on main should not impact v1. Any releases for v1 would happen on the v1 branch, but v1 is deprecated and unmaintained, so I don't expect new releases anyway. In any case, if you are using go modules to correctly pin to a v1 version, nothing should change for you.

The v2 subdirectory is not necessary for compatibility afaik. Popular projects like https://github.com/redis/go-redis, which is on v9, does not have a v9 directory. The v9 is just part of the name of the module as defined in the go.mod file. The only reason a v2 directory existed on this repo is because there was a period of time where both v1 and v2 co-existing on the main branch. This is no longer the case, so I think it is safe to clean up the v2 directory. If` you have evidence that this is unsafe, I am happy to reconsider.

Closing this issue since it seems like nothing is actually broken right now.