-
Notifications
You must be signed in to change notification settings - Fork 16
Conversation
Otherwise, we'll run into problems if we ever want to release a (semantic) version v2 of this package.
Was this not supposed to be the "v2" release? |
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. |
lets add a go.mod and keep it as is
…On Fri, Aug 27, 2021, 21:03 Marten Seemann ***@***.***> wrote:
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.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#138 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAI4SUF5WWGLXNVWUFZXYDT67HPDANCNFSM5C5FLG6A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
What’s the point? Why would we skip v1? I don’t think we should mix up protocol versions and API versions. |
If we actually want to maintain this code in two different Go modules, how about moving the v2 implementation into go-libp2p? |
it is version 2 of the protocol; the vagaties of go's api versioning is
immaterial. Also, we are not skipping anything, we stay at 0 versioning.
…On Fri, Aug 27, 2021, 22:01 Marten Seemann ***@***.***> wrote:
What’s the point? Why would we skip v1? I don’t think we should mix up
protocol versions and API versions.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#138 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAI4STE3PPEEJUPL7T5EEDT67OKHANCNFSM5C5FLG6A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
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
I think calling this the "v2" protocol is probably fine, honestly. |
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. |
I know. This would be the semantic v2 version, that was the idea. |
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... |
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.
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. |
Sorry, I did not mean to close this PR like that.
Fair enough.
Go for it. There's really no reason not to make it live in go-libp2p, as far as I know. |
Otherwise, we'll run into problems if we ever want to release a (semantic) version v2 of this package.