Module naming of services with multiple versions

It’s your project so do what you want! Credo is highly configurable for a reason

Ultimately what truly matters is if you and/or your team are finding the naming convention intuitive and easy to work with. If so, just tell credo to shut up about this one particular thing.

While using module names for versioning is extremely convenient, as the compiler can ensure their uniqueness, I would personally opt for the variant of placing the versioning as metadata in the module:

defmodule Test do
  use ServiceA, version: "1.2"
end

This gives much more flexibility in your versioning convention and doesn’t require you to be careful about how you name the modules.

Thanks dimitarvp and sodapocan! I interpret your answers as “yes, you can name your module as V1_0 if you want” and I probably will.

Thanks. If I understand your suggestion correctly, what you are suggesting is more related to “how to use the service” within the context of some other module.

In my case, the schemas for the services are auto-generated from an XSD schema. And there are multiple versions of the specification, where the specification defines multiple services. So each release of the specification will map to a separate module/namespace, e.g. ProjectX.V1_0. Within this module, there will be services like ProjectX.V1_0.DeviceService or struct definitions ProjectX.V2_1.DeviceService.TripInformation and so on.

So, right now, I am more focused on the code generation and codec, not so much on “how to use the services”

No, I’m not. I suggest you to not define the version in the module name, as you have limited control and tools over management of that.

Instead of having the version as the module name, with a little metaprogramming, you can have it in your module, for example my example can generate a function:

> MyService.__service_version__()
"1.2"

Anyway, if the initial version works, just go for it, as my version implies knowledge of metaprogramming. I just wanted to list an alternative.