This might not be the right place for this but I figured I could probably find a lot of people in the Scala community who at least recognise the problem I am trying to get at.
We are publishing our own ScalablyTyped libraries so that we only have to generate the code once and we can share them across all of our Scala.js projects.
Let’s take react-relay version 11.0.2 for example.
We could publish something with a POM like this:
<groupId>com.goodcover.web.typings</groupId>
<artifactId>react-relay_sjs1_2.13</artifactId>
<version>11.0.2</version>
We want the version to stay in sync with the downstream version of react-relay. However this creates a problem. What do we do if our build changes or we make some modifications to the generated source or change the version of ScalablyTyped? We need to change the version somehow.
One way is to append a pre-release suffix such as 11.0.2-1.2.3 which isn’t great but it mostly works.
Another way is to append it to the artifact id like we do for Scala.js and Scala. Such as react-relay_gc1.2.3_sjs1_2.13 which is pretty grotesque but highlights the extent of the problem.
This a general problem of cross building. When cross building we have our main version, say 1.2.3, and we have other orthogonal versions which are extremely important to the compatiblity but which are independent of the main version, such as Scala 2.13 or Scala.js 1.
The real version is the cartesian product of each of these independent version axes.
I don’t think we have a great solution to this. Neither the artifact id suffix or pre-release version suffix is great.
I had an idea that I wanted to get some feedback on. What if we could extend SemVer to support multiple version axes?
It could be something like 1.2.3/rr=11.0.2/scala=2.13/sjs=1.
The main version is 1.2.3 and would typically be fixed for a build. The other versions are separated by a / and then have a label= prefix followed by a SemVer version. These other versions represent the version of each dependency in our compatibility / build matrix. The reason for the label is because there likely needs to be a way to add or remove axes over time.
I floated this idea over at the SemVer repo in an issue but possibly tried a bit too hard to sell this in the context of TypeScript and go shutdown.
Thoughts?