This issue is all about versioning and how we want to handle it.
Background
gRPC is designed with the philosophy that you maintain backwards compatibility as much as possible and that, when you cannot, you provide a new API while maintaining the old API (at least until you are sure everyone has migrated).
Therefore we need to think about how we will handle this in DCS-gRPC
Options
Embrace versioning throughout the stack
To this end the recommended (and kind of required by Java and Go clients apparently) namespace format is. package.version so, for example. Our atmosphere package should actually be atmosphere.v1 and if we ever add a breaking change to any of the APIs then we add an atmosphere.v2 package and clone the .proto and make our changes in the new proto. (This is also reflected in the folder structure).
However if we completely embraces this concept then we need to do two things.
- Update the rust to become version aware (I am not sure if this requires extra rust code or if we just need to add the versioned services for example).
- Make all of our Lua code follow this same versioning pattern which would result in something like
GRPC["methods"]["atmosphere"]["v1"]["getWind"] = function ... and mirroring the proto folder structure in that respect.
The issue with this is that we would end up loading all of the different versions of lua into the scripting environment which kind of goes against our concept of "more performance" but I am not sure if loaded but unexecuted lua is actually that much of a problem. There might be issues with streaming if there are streams coming from two different versions and we are trying to optimised but that scenario might not happen (Or we can make streams the exception in that we will only support 1 version at a time).
Only update version if the interface changes
We only create a new version if we change the public interface. Changes to the lua implementation will not prompt a version upgrade requirement. This allows us to always have just one implementation of lua instead of multiple versions.
No versioning
We do not do any gRPC / code versioning and rely on semantic versioning to allow clients to decide if they want to upgrade their servers and clients. I did this with the demo apps and, with the help of an IDE admittedly, it wasn't that painful.
Final thoughts
I am not actually against any of the above options. I think the full versioning option is the proper option if we think we will have many different clients (which is actually a hope of mine so that adds weight to this argument).
Otherwise I think we should just go with no versioning. I think the "interface change only" option brings extra complexity without any appropriate benefit.
No matter what options we choose I think we need to do the v1 package naming to make things easier for Go and Java clients anyway and I think we should do it now since we are making big refactoring changes anyway.
This issue is all about versioning and how we want to handle it.
Background
gRPC is designed with the philosophy that you maintain backwards compatibility as much as possible and that, when you cannot, you provide a new API while maintaining the old API (at least until you are sure everyone has migrated).
Therefore we need to think about how we will handle this in DCS-gRPC
Options
Embrace versioning throughout the stack
To this end the recommended (and kind of required by Java and Go clients apparently) namespace format is.
package.versionso, for example. Ouratmospherepackage should actually beatmosphere.v1and if we ever add a breaking change to any of the APIs then we add anatmosphere.v2package and clone the .proto and make our changes in the new proto. (This is also reflected in the folder structure).However if we completely embraces this concept then we need to do two things.
GRPC["methods"]["atmosphere"]["v1"]["getWind"] = function ...and mirroring the proto folder structure in that respect.The issue with this is that we would end up loading all of the different versions of lua into the scripting environment which kind of goes against our concept of "more performance" but I am not sure if loaded but unexecuted lua is actually that much of a problem. There might be issues with streaming if there are streams coming from two different versions and we are trying to optimised but that scenario might not happen (Or we can make streams the exception in that we will only support 1 version at a time).
Only update version if the interface changes
We only create a new version if we change the public interface. Changes to the lua implementation will not prompt a version upgrade requirement. This allows us to always have just one implementation of lua instead of multiple versions.
No versioning
We do not do any gRPC / code versioning and rely on semantic versioning to allow clients to decide if they want to upgrade their servers and clients. I did this with the demo apps and, with the help of an IDE admittedly, it wasn't that painful.
Final thoughts
I am not actually against any of the above options. I think the full versioning option is the proper option if we think we will have many different clients (which is actually a hope of mine so that adds weight to this argument).
Otherwise I think we should just go with no versioning. I think the "interface change only" option brings extra complexity without any appropriate benefit.
No matter what options we choose I think we need to do the
v1package naming to make things easier for Go and Java clients anyway and I think we should do it now since we are making big refactoring changes anyway.