Suppress the API breakchange introduced by PR 1354 and bump up minor version

[LittleLittleCloud]

#1354 introduce API break change, we need to check in a suppression file to overpass the API compatibility check and bump the version

[NiklasGustafsson]

Let's fix the API breakage instead of suppressing it. @yueyinqiu -- if you could resubmit your earlier PR, without removing the single-parameter 'Connect', that would be helpful.

[yueyinqiu]

Hmm... I will check that. I just considered about the compatibility of the source code and ignored the binary compatibility.

I think that pr could be modified to hold the extra overloads thus keeping binary compatibility, but I wonder what should we do if there have to be some API changes? I think in the current stage API changes are still common and welcomed.

[yueyinqiu]

I'm also facing some problems when checking the API compatibility locally.

I tried dotnet pack, and Microsoft.DotNet.ApiCompat.Task.ValidatePackageTask failed because of the non-existence of ...\TorchSharp\pkg\TorchAudio\torchaudio\0.102.6\torchaudio.0.102.6.nupkg.

The first problem is that actually it should be compared with v0.102.7 instead of v0.102.6, since I'm developing for the future v0.102.8. Second, what's the best to approach to get the previous version? Here are many packages and for each one we have to create a directory and paste the file. So manually downloading them from nuget.org seems to be a bit annoying... Third, we should add the check into the checks of pull requests.

Actually I still believe it's too early to check about the API compatibilities.

[alinpahontu2912]

@LittleLittleCloud Thank you for reporting this issue regarding the API break change introduced by PR #1354. We've had some discussions about it, particularly the suggestion from @NiklasGustafsson to fix the breakage rather than suppress it. I wanted to check in with you to see if this issue is still relevant or if it has been resolved since the last update.

Additionally, if you have had a chance to look at the linked PRs #1357 and #1386, did they address your concerns? TorchSharp has evolved significantly over the past couple of years, so any updated information you can provide would be greatly appreciated! Thank you!

[yueyinqiu]

I believe this issue was specific to the environment at that time, which also resulted in a explicit packaging failure. We can safely close it for now and when we encounter the same problem in future, we can always reopen it or create a new issue. (Also for #1356. I think suppressing them one by one was just a workaround at the time, not a final solution.)

[alinpahontu2912]

Closing this for now