Cut a release

[alecholmez]

I think it's about time we move to v1.0 since many people are requesting it. If we follow the multi-module pattern with go.mod it shouldn't be too much of a burden to version the protos separately.

Are there any major features we would like to get in before we cut this? I think the list right now is:

• SOTW variants
• Benchmarks
• Linear/Mux Delta xDS cache support

Potentially revisit any critical bugs before 1.0 as well?

[snowp]

We might also want to look at some API changes that might be helpful to do before we move to a stable release, e.g. the existing NewSnapshot API is a bit unfortunate as it requires breaking the func signature every time a new type is added (https://github.com/envoyproxy/go-control-plane/pull/469/files), vs NewSnapshotWithResources that is more future proof.

Not sure how far away we are from not needing to special case resource types - if we can get to that point I think we could greatly simplify the snapshot API

[alecholmez]

@snowp I agree, I think this might be worth simplifying now. I'll see what I can do and then maybe we cut.

[kyessenov]

#461 would be good to have. It helps with controlling the order of responses.

BTW, what was last decided about envoy protos versioning? Are we OK with having "alpha" APIs in v1?

[alecholmez]

Agreed @kyessenov, I'll see if I can shepherd along that PR and push it through.

I'm not sure we ever made a final decision. I'm personally okay with it since the versioning the protos independently

[sunjayBhatia]

Are you targeting a specific date to cut v1.0? Do you have any guidance for what changes will be or will not be considered to merged afterwards? Or a schedule for further minor/major releases? The Contour project is hoping to do some work soon to modernize our xDS and may want to make more frequent future contributions

[alecholmez]

@sunjayBhatia negatory, we do not have a specific target date, I guess it would be as soon as possible.

Do you mean merged after we cut 1.0? We don't have a roadmap yet, I would like to create one though if at all possible. We're open to ideas!

I will say that list in the top is definitely something we want to accomplish before 1.0. As well as the snapshot API rework and protobuf upgrade

[snowp]

I would expect the main restriction on what gets added afterwards is breaking changes on the API, but I don't think that would be a huge limiting factor since we can get pretty far without having to change the public APIs

[alecholmez]

Nice thing about semver is we can just bump the version when we need to break :)

[sunjayBhatia]

Do you mean merged after we cut 1.0?

Yeah, was wondering how feature development would go after 1.0, pretty open ended question sorry I'm not sure yet what enhancements Contour may want/need yet in this space

following proper semver +1, if we have any big changes we will try to communicate properly in case we need to plan accordingly with the roadmap

[github-actions]

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.

[jpeach]

not stale

[github-actions]

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.

[jpeach]

Not stale

[alecholmez]

This needs to be addressed before we cut 1.0:

#403

[alecholmez]

A release has been cut, not 1.0 yet but we've cut 0.10.0

[SimonPrague]

A release has been cut, not 1.0 yet but we've cut 0.10.0

Did you make the release twice or something ..
As this release broke my project:

verifying github.com/envoyproxy/go-control-plane@v0.10.0: checksum mismatch
        downloaded: h1:ZyeIGk3fCB8NNzihPKZsCNCc7oTz7IgMsEy0E2G3iu4= 
        go.sum:     h1:WVt4HEPbdRbRD/PKKPbPnIVavO6gk/h673jWyIJ016k=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.  

This usually happens when Go packages makes two releases with the same number or something. If you can make a new fake release and bump the version you would fix this problem for everyone! But as of now this release probably broke many projects.

Thanks!

[StevenACoffman]

ugh. Broke my stuff too. Until a new release is cut that does not have a bad checksum:

go get -d github.com/envoyproxy/go-control-plane@main
go mod edit -exclude github.com/envoyproxy/go-control-plane@v0.10.0

[christieyang]

I meet the same problem
checksum mismatch
github.com/envoyproxy/go-control-plane@v0.10.0: verifying module: checksum mismatch downloaded: h1:ZyeIGk3fCB8NNzihPKZsCNCc7oTz7IgMsEy0E2G3iu4= sum.golang.org: h1:WVt4HEPbdRbRD/PKKPbPnIVavO6gk/h673jWyIJ016k=