Support more extensibility around versioning formats about aspnet-api-versioning HOT 2 CLOSED

To be clear, are you talking about the version of the API surface area or the implementation version of the service. I hate to insert dogma here, but there is a distinct difference; one that I see a lot of service authors mix up.

An API can't really have a build, revision, or patch version in any sensical meaning of the work. I agree the implementation absolutely can. Clients never care about revision, build, or patch changes; such version are invisible to clients because there is no change to the surface area (and likely the behavior).

As it stands, the ApiVersion is a key primitive in the library. I'm not opposed to adding more flexibility and options, but this one is probably deep. It's more than just the Equals method. The ApiVersion class support comparisons too so that you can enable scenarios like apiVersion2 > apiVersion2. This can still be enabled with some refactoring, but there are quite a few things that would have to change to enable it.
I've worked with teams internally that had similar needs. Their solution was to simply provide a mapping between ApiVersion and System.Version. While it's convenient for them to be the same, it shouldn't be a deal breaker. Is that not an option for you?

It seems like tracking revision and build versions for a service client is quite the burden. The basic expectation and assumption is that these would be compatible. The question for the client then becomes, "Should I update" or "When should I update"?

If there's a way to bridge or map the two styles of versions within the service, then that's the best way to go. If that doesn't work for you, then I'd love some any additional details you can provide. I'm not opposed to improving flexibility, but I want to make sure we're making the changes for the right reason,

from aspnet-api-versioning.

Thanks for taking the time to answer so clearly @commonsensesoftware. I agree with all your points, and on consideration, our use case is probably too specific to be worth supporting. For completeness, I'll try to be more clear about our particular use case, but if it is too far off what you are wanting to support, I'm happy to leave it at that.

Our API is only consumed internally by a single web app, so we currently get away with versioning our API and web app together using a format x.y.z, where x and y are under manual control, and z is automatically generated by our build system. We are therefore not following System.Version guidelines, we are just using System.Version as a container for 3 numbers.

We don't keep track of whether the API surface has changed between releases, so we assume every release has breaking changes. If we were following the Microsoft versioning semantics, we would just have a major version, incremented every release. It just so happens that our major version is actually 3 numbers.

It may be most semantically correct therefore to automatically combine those 3 numbers into a single major version for the API. It's just unfortunate that there is then an artificial mismatch between the web app version and the API version it consumes.

from aspnet-api-versioning.