Semantic versioning

[ImpPhil]

Intel Nuget package version numbers don't conform to semantic versioning standard causing package resolution issues.

Semantic versioning uses X.Y.Z with additional X.Y.Z-a.b.c. reserved to indicate preview/beta versions.  2030.0.0.25930 doesn't conform.

This intelmkl.redist.win-x64 has these dependencies

and since the dependent packages also have invalid version numbers Visual Studio throws these warnings

I can only suggest you switch to using for example 2030.0.25930.

[ShanmukhS_Intel]

Hi Philip,

Thanks for posting on Intel Communities.

Thanks for sharing the details. We would like to inform you that, the packages resolution would not be a problem as the packages would fetch for 

an alternative best match.

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi Philip,

As the same question has been raised on the below thread as well, could you please let us know if we could continue addressing this issue on the below thread and close this?

Reference URL:

https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/vzMul-performance/m-p/1441909#M34067

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi Philip,

We are discussing your issue internally. We will get back to you with an update soon!

Regrets for the delay in response.

Best Regards,

Shanmukh.SS

[ImpPhil]

To add to your discussion, several Nuget packages (I'm thinking MKL.NET and Mathnet-numerics ) use Intel MKL as a native provider.  Unfortunately they both use custom builds of MKL which means if my app uses both MKL.NET and Mathnet-numerics, I end up downloading two different builds of MKL, each taking ~200Mb. 

If you resolved this issue and https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/IntelMkl-redist-linux-and-osx-nuget-packages/m-p/1442758#M34099 then hopefully MKL.NET and Mathnet-numerics (and others) could reference your nuget package, which would simplify dependencies.

[ShanmukhS_Intel]

Hi Philip,

We would like to inform you that, as the first three components of the versioning can already locate the package and the fourth component is just an extension. Hence the existing versioning could not be considered a bug.

Best Regards,

Shanmukh.SS

[ImpPhil]

I disagree.  The semantic versioning standard is explicit that you should use Major.Minor.Patch only.  Since nuget uses this standard your Nuget packages should conform, or you get problems as shown below.  Your mkl package has a dependencies of 

If you released a new version of one of the dependencies that only incremented the 4th component then this won't be located correctly, as is the case here.

[ShanmukhS_Intel]

Hi Philip,

Thanks for sharing your feedback. We are discussing your issue internally. We will get back to you soon with an update.

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi Philip,

As discussed, NuGet packages fetch the dependencies with the approximate best match in case of any mismatch. As mentioned by you, For version 2030.0.0.25930, as per semantic versioning, 25930 indicates the build. Regarding the oneAPI component versioning schema, please go through the below link.

https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-toolkit-and-component-versioning-schema.html

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi Philip,

A gentle reminder:

It had been a while since we heard back from you. Could you please let us know if you need any other information.

Best Regards,

Shanmukh.SS

[ImpPhil · Accepted solution]

I don't accept your reply as a solution.  An approximate best match causing a warning is less than ideal.  However please close this as I have lost interest. 

[ShanmukhS_Intel]

Hi Philip,

Thank you for your feedback. We have provided your feedback to the relevant team. However, at this moment there is no visibility when it will be implemented and available for use.

Best Regards,

Shanmukh.SS