-
Notifications
You must be signed in to change notification settings - Fork 514
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
Develop release policy #391
Comments
@kyessenov - is this something you would be able to do? I also filed cncf/xds#2 to cover a dependency of this repo's (or cncf/udpa#42 if the protos are still coming from the deprecated UDPA repo). |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
Is there a 'never stale' label we can apply here? also, cc @htuch |
I don't think we currently have the resources to manage releases on this repo, but I will mark this help wanted for now. |
Proposal 1: the "quick and dirty" option if you don't mind releasing the go-control-plane server implementation as stable
Proposal 2: version only the
|
Are there concerns about implementing one of the two proposals above? Managing releases doesn't need to be complex or time consuming. |
@kyessenov @alecholmez @snowp thoughts? |
I don't see a problem with it if ya'll are willing to do the work :) I would think the second option of only versioning the protos would be the safest, I think that would also allow projects to import the protos without importing the whole control plane code? If so that might provide additional benefits as well |
@htuch @mattklein123 I'd be more than happy to take this over and manage this! Would love to chat with you guys and potentially talk about future goals as well |
I'm happy to help out as well! |
Because it's in the same repo, I believe the rest of the control plane code would be downloaded by any application using only the protos. But this would only be a minor cost, and external dependencies of packages not used by the application are not downloaded in either case. |
I'm fine with the independently versioning the protos as well. It captures the right backwards compatibility expectations from Envoy APIs without tying the control plane to its existing interfaces. My main concern is the technical: how to achieve that with minimal pain. It was quite painful to have multi-module repos in the past, and I haven't revisited this subject in awhile. |
On the second thought, Envoy APIs do have "alpha" packages that can have breaking changes. It would not be right to have "v1" with those packages. I think we'd need to pull out those extensions out of v1-versioned module if we are to follow this plan. |
@kyessenov see my comment above for how to do multi-module repos here. We have several modules in https://github.com/grpc/grpc-go, and it's not difficult to manage.
As long as they are very clearly indicated as such via the package name or comments visible via godoc, it should be safe to include alpha packages that are not subject to semver in a v1.x Go module. |
I have no negatives on the multi-module repo versioning. I will say I think it's important we do version the logic external to the protos in this repo though. Quite a few large projects depend on the code in here (that are past v1.0) and IMHO it's important we don't break them (especially when landing things like incremental which make API changes). Regarding the alpha protos, I agree with @dfawley, it's a users risk using an alpha versioned dependency. Alpha does not mean stable but I think it would be the job of THIS repo to make sure that is known as well as make sure we version in a way that is inclusive to the fast moving nature of the proto stubs. +1 for me on the multi-module versioning but I think we need to call this repo a |
Hi all, I made this document: Proposal: Multi-Module Release Plan @dfawley Feel free to edit as you please or add yourself as a doc owner. This was your proposal after all. I think it might be worth outlining what importing this project would look like if we're going down the multi-module route |
The doc LGTM, but you may also want to explicitly capture steps 2-4 in my comment, which are also important. The process for importing packages in this repo wouldn't change for users. Users would probably want to do a |
Is there a path forward here? How can we make this happen? |
It seems like there is consensus on using multiple modules. Is there anything else to discuss before this gets implemented? |
would there be any appetite in the sub-module tag being cut/based on Envoy release version? e.g. when envoy X.Y releases, the automation to mirror the API changes would also tag thinking about the case(s) where new fields are added to the protos but you may be relying on an older Envoy version etc. |
@sunjayBhatia I think that might actually be a good idea. If we can automate that whenever they cut their release it triggers a sub module release on this end that would be very cool. This was originally high on my priority list but I let it fall off. I'd say let's revisit |
There are cases where you need both the old and new protobuf definition to bridge an API change. The first part of this problem is having both of the generated definitions (I think the submodule version proposal works for this). The second part is swizzling the types in the protobuf registry so you don't have 2 types trying to claim the same name. Not sure how to deal with that part. |
@sunjayBhatia making the Go modules change now would only be useful for Envoy 1.21 and later, right? |
yeah if tying it to Envoy releases works/we do that, it would only be useful going forward |
Actually, it might be possible to tag the submodule with older versions of the envoy protobufs. Would need to do some branching and tedious manual hackery, but could be doable? |
Honestly it might not be worth the hassle. If users need compatibility with an older version they can just pin (similar to what we did with the v2 removal). IMO i think it's easiest to just tag the submodule, list compatibility as 1.21 and document if you'd like an older version of envoy please use previous releases of go-control-plane. |
See also discussions in envoyproxy/envoy#28041 and #723. |
gRPC-Go has several 1.x releases that depend upon this repo extensively for xds support. If a breaking change were to happen here, it would break gRPC-Go users.
If there are concerns about some parts of the repo being unstable, then we would be happy with a sub-module inside
envoy
that can be released as a stable v1 for the generated proto messages.See also cncf/udpa#42. I believe this repo would also need a v1 release from the UDPA repo, since it is a dependency of several protos here.
cc @htuch, @markdroth
The text was updated successfully, but these errors were encountered: