Change published versions naming scheme from "8.4.1.jre11" -> "jre11.8.4.1"

[stolsvik]

The current scheme is problematic wrt. Gradle's ability to specify a "+" on the version string, e.g. "8.4.+". Semver schemes should always allow for this, so that one can "hang on" to revision bumps, which by definition should not change any functionality, only make things "better" on the same major.minor.

However, the practice of sticking on a Java version as a suffix makes this impossible.

From a conceptual angle, I'd also argue that the "majorest" part of a version scheme where you want to include the JRE dependency as a part of the version string, is the JRE version, not the "8".

[mprins]

That might break Maven versioning logic.
I would prefer the Java API level not to be part of the version at all, but part of the artifactId, eg. mssql-jdbc-jre8.9.2.0

FWIW postgresql doe sthe same thing, appending the Java API level to the version, however only for "lower" version API levels (see eg. https://search.maven.org/artifact/org.postgresql/postgresql)

[harawata]

How about using classifier?

https://maven.apache.org/pom.html#dependencies

The classifier distinguishes artifacts that were built from the same POM but differ in content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier jdk11 and the second one with jdk8 such that clients can choose which one to use.

The <dependency /> entry in a user's pom.xml would look as folllows:

<dependency>
  <groupId>com.microsoft.sqlserver</groupId>
  <artifactId>mssql-jdbc</artifactId>
  <version>9.1.1</version>
  <classifier>jre8-preview</classifier>
</dependency>

I'm not sure about Gradle, but this should work better with Maven + Dependabot (not verified).

As an example, older versions of TestNG used this technique.
The repo looks like this: https://repo1.maven.org/maven2/org/testng/testng/5.9/

[TarasTielkes]

combining the Java version and the driver version in one segment seems an opportunity for more confusion

[mprins]

oracle has always had the Java API version as part of the artifactId, eg ojdbc8, ojdbc10 etc. https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc10/

[peterbae]

Thanks for the input everyone, I'll keep this issue open for more discussion, and the team will review the options when we reach a consensus on whether it would be best to keep current convention or switch, and if so, which one to choose.

[stolsvik]

Evidently Gradle handles classifiers fine: https://stackoverflow.com/a/13322127/39334

However, I'd personally prefer the Oracle way (as a part of the artifactId) if the version scheme I suggested ("jre11.8.4.1") is not viable, as I find that classifiers aren't used much; I have no such classifier-specifying dependencies in any of my projects.

[stolsvik]

That might break Maven versioning logic.

Why would that be? I do not believe it would break neither Maven nor Gradle's version logic - it is pretty much alpanum sorted, with dots and dashes handled as separators for the different parts of a version. AFAIU, a version specifier like "jre8.+" would even work as expected. A version specifier of "+" would not, though.

Here's a SO answer that deals in letters, but that is with postfixes like -RC and similar. Should be simple to check out, it seems like. https://stackoverflow.com/a/31482463/39334

.. but even given that, the oracle-way might be better? The jre-version is not strictly a part of the version of the MS JDBC driver code, but I still argue that it would work in practice, and would solve the clear problem the current naming scheme has.

[David-Engel]

Changing the version scheme like this is a nice thought. But we would only do it on a major version bump. We'll consider it in the future.

So far, I think the classifier option looks the cleanest but I wonder if it will work for everyone. I think the "jre11.8.4.1" format looks odd. "jre11.8.4.1" looks like a higher version than "jre8.9.2.1" at first glance. Anyway, not making a decision now, just discussing.

Also, while this might seem like a simple thing to change, it would affect downstream test pipelines, docs, etc., that would require work to update and support.

[s-seidel]

Please consider using the classifier. It is the cleanest way to do it. In fact, the Maven documentation explicitly states this as a use case:

As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier jdk11 and the second one with jdk8 such that clients can choose which one to use.

The current scheme is not very good when trying to stay at the latest version for a given JDK, because the .jdk16 version will always be considered "newer" than the .jdk11 one.

[gastaldi]

+1 to use the classifier. IMHO using the JDK in the major version part is wrong because when comparing versions jre9.8.4.1 > jre11.9.0.0

[manticore-projects]

As long as I do not use very specific features of the JDBC driver, I would always want the "latest, greatest" version. In Gradle, normally I can achieve that easily with:

implementation 'com.microsoft.sqlserver:mssql-jdbc:+'

However, due to the suffix, this does not work and I have to hard code the version in my build file:

implementation 'com.microsoft.sqlserver:mssql-jdbc:12.6.0.jre11'