Missing previous releases of cloudsql-proxy about cloud-sql-proxy

[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!