Skip to content
This repository has been archived by the owner on Sep 9, 2022. It is now read-only.

rename the v2 directory to circuitv2 #138

Closed
wants to merge 1 commit into from
Closed

Conversation

marten-seemann
Copy link
Contributor

Otherwise, we'll run into problems if we ever want to release a (semantic) version v2 of this package.

Otherwise, we'll run into problems if we ever want to release a (semantic)
version v2 of this package.
@Stebalien
Copy link
Member

Was this not supposed to be the "v2" release?

@marten-seemann
Copy link
Contributor Author

We’re currently at v0.x, so unless we want to skip v1, I don’t think so. Also, there’s no go.mod file in the v2 directory.

@vyzo
Copy link
Contributor

vyzo commented Aug 27, 2021 via email

@marten-seemann
Copy link
Contributor Author

What’s the point? Why would we skip v1? I don’t think we should mix up protocol versions and API versions.

@marten-seemann
Copy link
Contributor Author

If we actually want to maintain this code in two different Go modules, how about moving the v2 implementation into go-libp2p?

@vyzo
Copy link
Contributor

vyzo commented Aug 27, 2021 via email

@Stebalien
Copy link
Member

What’s the point? Why would we skip v1? I don’t think we should mix up protocol versions and API versions.

Well, it changes both right? (and the user could import both if they really want to). IMO, using versions is strictly less confusing than having a circuitv2 folder. The alternative would be to:

  1. Have two folders, one for the old protocol, one for the new. But that's a large breaking change.
  2. Yet another repo...

I think calling this the "v2" protocol is probably fine, honestly.

@marten-seemann
Copy link
Contributor Author

Ok, so I probably should have explained this better.

The problem with naming the folder v2 is that once we release an actual (semantic) v2.x.y, one way of doing that would be adding a v2 folder (see https://go.dev/blog/v2-go-modules), which we can’t do, since that path already exists.

@Stebalien
Copy link
Member

I know. This would be the semantic v2 version, that was the idea.

@marten-seemann
Copy link
Contributor Author

We could do that, but I don't think it's a good idea to couple protocol version and code version.
For a brief moment we'd have v2.x == circuit v2, but with the next API change (or dependency update), we'd have v3.x == circuit v2, which would be pretty confusing.

@Stebalien
Copy link
Member

We could do that, but I don't think it's a good idea to couple protocol version and code version.

That's a good point, but I really don't like the current approach as it makes it unclear which version should be used. What if we released a v2 (API) with two subdirectories (one for each protocol)?

Alternatively we can make a new repo...

@Stebalien Stebalien closed this Aug 27, 2021
@marten-seemann
Copy link
Contributor Author

What if we released a v2 (API) with two subdirectories (one for each protocol)?

We could have two subdirectories, one for each protocol, and just release that as v0.5.0. Really, there's no need to do anything special with our semantic version at all.

Alternatively we can make a new repo...

What about moving the new version to go-libp2p? We're going to deprecate circuit v1 at some point, and as soon as we do that, we'd have reduced the number of repositories. The justification for moving this to go-libp2p would be that circuit v2 is a protocol that every (publicly reachable) node would run.

@Stebalien Stebalien reopened this Aug 27, 2021
@Stebalien
Copy link
Member

Sorry, I did not mean to close this PR like that.

We could have two subdirectories, one for each protocol, and just release that as v0.5.0. Really, there's no need to do anything special with our semantic version at all.

Fair enough.

What about moving the new version to go-libp2p? We're going to deprecate circuit v1 at some point, and as soon as we do that, we'd have reduced the number of repositories. The justification for moving this to go-libp2p would be that circuit v2 is a protocol that every (publicly reachable) node would run.

Go for it. There's really no reason not to make it live in go-libp2p, as far as I know.

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

Successfully merging this pull request may close these issues.

3 participants