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 is removed #319

Closed
jerome-laforge opened this issue Jan 31, 2024 · 4 comments
Closed

V2 is removed #319

jerome-laforge opened this issue Jan 31, 2024 · 4 comments

Comments

@jerome-laforge
Copy link

jerome-laforge commented Jan 31, 2024

With #318 & f0cd8fa, 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
Copy link
Owner

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:

  • It sounds like you are depending on v1 of the library and not v2, is that correct?
  • Are you using a tool like Go modules to version your dependencies?
  • What version of Go are you using?

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
Copy link

nohajc commented Jan 31, 2024

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
Copy link
Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants