Missing previous releases of cloudsql-proxy

[udoprog]

Hey,

I'm trying to deploy cloudsql-proxy, but one of the issues I'm facing is managing releases.

It appears that you only expose one version at a given time (only the tag for 1.05 is visible) which makes it really hard to reproduce a build for an old version.

It also appears that the binaries you provide does not contain the version number, I assume this means that they are always the 'latest'. I'd like to package one specific version and in order to do it securely I want to be able to verify its checksum. If this changes over time (a new version replacing the old one) this will no longer work.

1) 'd like to ask that you provide a URL for downloading the static binaries which include the version number. Guarantee some kind of retention for old versions (e.g. 6 months).
The URLs I'm referring to right now are the ones listed here:
https://github.com/GoogleCloudPlatform/cloudsql-proxy/releases

2) Can we guarantee that tags for old releases remain available after a new release is made available. This would allow us to setup a build for the project, but without it, it would be something we would have to attempt to maintain ourselves.

3) What guarantees do you intend to provide between Major vs. Minor version bumps? You do not appear to use semantic versioning right now so this is unclear.

Thank you for your time!

[Carrotman42]

Hey there, glad to hear you're using the Cloud SQL Proxy! Please continue to open feature requests for anything else that would make that sort of setup easier, along with any issues the Proxy caused.

1. Sure thing, for the next release I'll try to get this set up. I'll keep the existing URLs and have them point to the 'latest' release after some amount of time, but I'll also release URLs to point to specific versions of the code.

Do you want me to post the hash of the binaries or do you want to do it yourself? If you want me to, can you suggest a place where it should go? I've been wanting to do this but can't think of the best place to put it for it to be easily accessible by automation. Maybe in the repo?

2. Are you referring to the docker containers that are released? If so, I recently was told that I should be doing this and have already started doing so. Before I always just updated 'latest', but now I will be doing the update in a staged way. That is, do a release and create a new tag for the release, and then after a bit of time update the 'latest' tag to be the new release. As of now, the 'latest' tag is version 1.04.

Let me know if there's some other way you think is best to do this.

3. Well, it's kind of semantic version, depending on your definition. (Barring bugs in the release) each release has been a non-breaking minor change from the previous version. Some of the releases probably could have been a patched version of the previous version (e.g. 1.03.1), I suppose. I can start doing the patched releases when it really is a small set of changes which just fix bugs.

As for guarantees, the thing that comes to mind is that I'll be changing the default of the -check_region to true instead of false, and at some point setting the flag to false will have no effect and the region will be mandatory (and it's likely that all previous versions of the proxy will no longer work). I suggest you start setting it to true on your own to ensure that you'll be ready for all of that. There's no hard plan about the full requirement to say the region when specifying instances, but the default flip will happen sometime soon.

There's still not a hard guarantee between versions though. There are not yet any plans to make breaking changes, and if any come up I will fight hard against them. But, as the Proxy and Cloud SQL evolve there may not be anything I can do about a breaking change due to some backend change I am not involved with (this is the case with the -check_region flag, for example).

[udoprog]

Great for fixing the URLs, that will help a lot. For me there's no need to publish the hash, we'll be generating them as new releases are made available.
For 2) I was referring to the git tags.
Also, thanks for clarification on 3), it's mostly about can be expected from future versions.

Thanks for the help!

[udoprog]

Hey, it also appears as if the current available binary doesn't match the latest version. I get the following issue when using the uploaded binary:

the default Compute Engine service account is not configured with sufficient permissions to access the Cloud SQL API from this VM. Please create a new VM with Cloud SQL access (scope) enabled under "Identity and API access". Alternatively, create a new "service account key" and specify it using the -credentials_file parameter

Which is not present if I compile master myself.

[Carrotman42]

Hmm, the static binary URL hasn't been updated yet.

It appears that I made a copy-paste error when doing the release :( It should be fixed by the end of today

[Carrotman42]

Forgot to update this bug. The static URL should be pointing to 1.05 now.

As for git tags, I will now be adding them each time there's a release. I just discovered this feature and I think it's great.

Please let me know if there are any more things you'd like answered!