api releases

[buchgr]

IIUC this repository wants to use semantic versioning but so far there have been no releases. I suppose my question is simple: Does a plan exist to start doing releases?

[ola-rozenfeld]

What's semantic versioning? I did plan to do releases, but kept postponing it because it wasn't a high priority. The reasons I thought to do it is that it would just be cleaner to have release notes and a set of changes in one place instead of letting people pin to a commit. Are there other reasons we should do it?

…

On Fri, Nov 23, 2018 at 5:25 AM Jakob Buchgraber ***@***.***> wrote: IIUC this repository wants to use semantic versioning but so far there have been no releases. I suppose my question is simple: Does a plan exist to start doing releases? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#39>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYoKuM4D7FFI5PgNw8ReJ9h-Xfn9uXPXks5ux80ngaJpZM4YwaoC> .

[akirchhoff-modular]

I'm confused about this too. There's a "v2" directory with a proto in it, and the ServerCapabilities message has SemVer fields for minimum and maximum supported version. So say I was implementing a server and I implement exactly what's in there right now. What version did I just implement? Version "2", if the directory name is anything to trust, but that only tells me the major version. So what's the current minor and patch version? Are we at 2.0.0, or maybe we're further along at 2.5.8 or something? I don't know right now, but I would like to know, and making actual releases would be an excellent way to clear that up for others in the future too.

[ola-rozenfeld]

That's a good point. Okay, let's make releases, then! We're at 2.0.0 because we've never given that thought until now :-) I'm thinking, should there be some sentinel VERSION file or something that contains the API version? So that people could access it programmatically ? Currently, we just hardcode 2.0.0 in Bazel, for example.

…

On Wed, Sep 4, 2019 at 8:28 PM alex-xnor ***@***.***> wrote: I'm confused about this too. There's a "v2" directory with a proto in it, and the ServerCapabilities message has SemVer fields for minimum and maximum supported version. So say I was implementing a server and I implement exactly what's in there right now. What version did I just implement? Version "2", if the directory name is anything to trust, but that only tells me the major version. So what's the current minor and patch version? Are we at 2.0.0, or maybe we're further along at 2.5.8 or something? I don't know right now, but I would like to know, and making actual releases would be an excellent way to clear that up for others in the future too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#39?email_source=notifications&email_token=AGFAVOGTT73PO7D53EAHOQDQIBHBHA5CNFSM4GGBVIBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD55NQVI#issuecomment-528144469>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGFAVODY3QKZ6DU6IWK6TTLQIBHBHANCNFSM4GGBVIBA> .

[akirchhoff-modular]

A version file could be useful for clarity when people are looking at the source tree, but I'm not sure programmatic access would be as useful as it might seem at first. For example, say some new version is released that adds a new feature with some new RPCs, and this new version is 2.1.0. Some organization that happens to maintain a server implementation, decides to bump all their dependencies to the latest version. For remote-apis, that means they get the new protos, but they haven't actually updated their implementation to handle the new RPCs. It seems to me that their server should continue to report 2.0.0 until they actually handle the new RPCs.

Whether we have a version file or not though, just having tagged releases would be a nice step up from where we are now.

[ola-rozenfeld]

Good point! Whether to use this programmatically or not should be at the discretion of particular implementations. I think clients are more likely to find it useful than servers.

…

On Fri, Sep 27, 2019 at 2:24 PM alex-xnor ***@***.***> wrote: A version file could be useful for clarity when people are looking at the source tree, but I'm not sure programmatic access would be as useful as it might seem at first. For example, say some new version is released that adds a new feature with some new RPCs, and this new version is 2.1.0. Some organization that happens to maintain a server implementation, decides to bump all their dependencies to the latest version. For remote-apis, that means they get the new protos, but they haven't actually updated their implementation to handle the new RPCs. It seems to me that their server should continue to report 2.0.0 until they actually handle the new RPCs. Whether we have a version file or not though, just having tagged releases would be a nice step up from where we are now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#39?email_source=notifications&email_token=AGFAVOEIUCJXECEISUR3VRDQLZFXDA5CNFSM4GGBVIBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ZXHLA#issuecomment-536048556>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGFAVOAX6ZTQF3LIHVA4PULQLZFXDANCNFSM4GGBVIBA> .

[ola-rozenfeld]

Okay, I released 2.0.0. I have not yet added any VERSION, CHANGELOG.md or other customary files (there are many options of getting the version programmatically, e.g. a version.bzl file).

All these can be addressed later, as needed; the important thing is that from now on, we will have formal releases (which I will try to make as frequently as needed, no SLA). In particular, 2.1.0 will be coming soon, as it will be required by #96.