To discuss: Strandard handling of service version

[saiyedzaidi]

We are missing a standard handling of service versions. At this time developers have to make custom logic and beans to implement the versioning in their way causing everybody writing the same code and config repeatedly. I would like to discuss about handling service versioning in

1. Authoring a service;
   • allow defining service version as a bootstrap property
   • use the version number as webapp context to prefix version number to all services automatically
   • the version number will not be prefixed to actuator if its enabled.
2. Discovery client;
   • Send service version as appropriate property if the actual discovery client supports it, otherwise fallback to serviceName-versionNumber convention as a serviceId
3. Config client;
   • Lookup up config using the specific service version, fallback to nearest or non version config if specific version is not found..

And further projects that can use the version property.

[ryanjbaxter]

Is this specifically to do with versioning APIs?

[saiyedzaidi]

Yes. I reckon every project will need to version the API and at this time they have to create custom solutions for it. I hope ultimately, we may define/choose conventions for versioned service registration, discovery, central configuration. But to begin with, the bootstrap should let services define their version along with the application name as a separate property.

[spencergibb]

Anything we do would have to work across multiple systems: eureka, consul, zookeeper, cloudfoundry and from incubator: kubernetes and etcd. I think your request has some specifics to zuul. Any specific strategy will not be a silver bullet to everyone, so whatever happens it needs to be flexible.

[saiyedzaidi]

Yes, the specific versioning strategies will be contained in the relevant implementations. But as the first base, we have to define the optional version-number property for the bootstrap. The implementation can be updated to use this property if its defined later/gradually and we can discuss each implementation separately. Until we change the implementations, there will be no impact anywhere.

[spencergibb]

I'm also saying that any specific strategy (ie version number in URL or versioned accept header) won't be ideal for everyone, that will have to be generic.

[ryanjbaxter]

I am also not sure the enforcing these versioning patters (with context root, and service name) will be necessary for everyone.

[saiyedzaidi]

I am of the opinion that without the version handling, the projects are not production ready and sort of incomplete. One must research for most popular way for version handling and match it with their needs and finally be forced to build it in. We can provide a starting point. Yes, I agree that everybody may not be using the same strategy. I am just after providing some defaults, which will be the most sensible or useful to most of the users. To keep it simple and limit the scope, for the service implementations, I proposed adding support for URL based versioning and using webapp context to force in the version number. But, also ensuring that users can override these defaults with their configuration just like everywhere else on Spring boot. If this makes sense, we may just choose some other handling as default. Similar choices will need to be made for every implementation that may need to use the version number and can be discussed one at a time.

[spencergibb]

I am of the opinion that without the version handling, the projects are not production ready and sort of incomplete.

That's a valid opinion. Assuming "the projects" means this one or other spring cloud projects, they are in production in various places already.

Some kind of versioning scheme would be necessarily opt-in.

[spencergibb]

We're not going to do anything with respect to versioning at this time.