microsoft/mssql-jdbc

Unpublished versions 10.2.4 and 11.2.4

OleksandrShkurat opened this issue · 8 comments

According to the issue
#2103
there were two other development tickets defined:

Many thanks for considering my request.

We'll take another look at this, but I believe the two hotfixes were not released because they were found to not be needed. A user having the above issues with 10.2.3/11.2.3 could use either 10.2.2/11.2.2 respectively, or use the later stable release in 12.2.0. We'll look again to see if these additional hotfixes are needed.

@OleksandrShkurat we're not able to release any hotfixes at the moment, but our recommendation is the above, either use a downgraded (10.2.2,11.2.2) or upgraded (12.2.0+) version of the driver, and the issue presented in 10.2.3/11.2.3 is no longer present.

Please let us know if this solution works for you. I noticed you also had an issue here (spring-projects/spring-boot#37794). If Spring Boot is using 10.2.3/11.2.3 then they will also need to follow the same advice and update the driver being referenced.

Please let us know if this solution works for you. I noticed you also had an issue here (spring-projects/spring-boot#37794). If Spring Boot is using 10.2.3/11.2.3 then they will also need to follow the same advice and update the driver being referenced.

We've overridden mssql-jdbc version directly in our project to 12.4.1 and it looks like it works.
However, the Spring-Boot team has a strategy of automatically upgrading 3rd-party dependencies inside some predefined ranges. So, for Spring-Boot 3.1.x there is a predefined version range for mssql-jdbc - 11.2.x. And version 12.x will be used since Spring-Boot 3.2.0
It means that almost every single Spring-Boot based project working in Azure is affected by this issue and is forced to redefine mssql-jdbc driver manually.
I don't think the Spring-Boot team will redefine this rule for currently going 3.1.x lineup.
At the same time, it sounds strange that hotfix releases are impossible on your side, taking into account that in fact the fix was implemented and, moreover, an appropriate issue has the comment that 11.2.4 release is created for it.

Glad to hear there is a solution.

It means that almost every single Spring-Boot based project working in Azure is affected by this issue and is forced to redefine mssql-jdbc driver manually.

I see how this may be an issue. We'll take another look once we're able to move out releases again, but I believe the decision from earlier, that a hotfix is not needed here because, for most cases, there is a reasonable alternative, would stand.

At the same time, it sounds strange that hotfix releases are impossible on your side

A hotfix is not possible in the immediate future as we're currently experiencing a blocker. Once this is resolved, we'll take another look whether this is something we want to re-address.

For the time being, since there is a solution, we will close this as resolved. If we do indeed decide to release an updated hotfix 10.2.4/11.2.4, we'll update this issue.

Thank you for the response

I don't think the Spring-Boot team will redefine this rule for currently going 3.1.x lineup.

I don’t think this rule makes sense for third party artifacts which have a different lifecycle policy or do not follow semver. I mean it’s ok to limit automatic bumps of dependency versions to minor versions, but as soon as there are real requests for newer (and compatible versions), they should have a manual process.

Having said that, is there a lifecycle defined in mssql-JDBC (or Ms commercial) for older major versions and how often they get updated, i did not notice many „branches“ before (and I think that’s reasonable)

Having said that, is there a lifecycle defined in mssql-JDBC (or Ms commercial) for older major versions and how often they get updated

Generally if there has been several stable releases since the release in question, additional hotfixes are unlikely to be released. In this case, since 10.2.3 and 11.2.3, there has been stable release 12.2.0, 12.4.0, and 12.4.1. We also take a look on a case-by-case basis, to see if the issue warrants an exception. We decided an exception was not warranted in this case, as there is a reasonable alternative through updating.