How should breaking changes be handled as it relates to semVer vs staying in-line with Orleans versions?

[Kritner]

#53 would introduce a breaking change to the package w/ the additional parameter added to the abstract method PerformWork.

The signature goes from:

protected abstract Task<TResult> PerformWork(TRequest request);

to:

protected abstract Task<TResult> PerformWork(
  TRequest request, GrainCancellationToken grainCancellationToken);

This is minimally breaking in that each grain implemented would need to just have the new parameter added, but it is breaking nonetheless.

Generally the packages release for this project have been kept in-line with the Orleans version. e.g. when Orleans 8 support was released for this package, the major version was revved to 8.

Going by semVer however, a breaking change necessitates revving the major revision to 9.

I have no idea how many folks are actually using this package, I have had some people put in issues and PRs, so it's probably safe to say not "0". That being said, what are the feelings regarding this "keeping the major version reflecting Orleans version support" or "going by semVer".

[Kritner]

@hendrikdevloed, @shersh, @DanSmith, @htxryan, @einari

I'm tagging folks that I've seen involved in either issues or PRs, feel free to ignore, but wanted to make you aware of this poll and get your thoughts. I'm not sure of anyone else to tag since I'm not sure who is actually using this 😅

[Kritner]

This would also be a valid concern for #52 - again probably minimally breaking, but still breaking.

[DanSmith]

Thanks for the poll Russ.
Any time I upgrade the version of Orleans I'm using, recently I have also updated the references and rebuild SyncWork due to the missing method I had once encountered as I mentioned in #46. That is why I voted for compatibility with specific Orleans versions than if the SyncWork API has changes/updates. Thanks again for your work on this library!