Closed wo80 closed 3 months ago
@wo80 Do you mind creating a minimal pull request reverting the problematic part? Then users like from upstream SciPy can confirm it fixes their issues and upvote the change.
Do you mind creating a minimal pull request reverting the problematic part?
Considering the history of failed attempts to contribute, yes, I do mind. So you do the fix, please.
And just to make this clear: merging #116 did break backwards compatibility, but that is actually the right way to proceed and it's not @xiaoyeli s responsibility to provide a backward compatible complex
definition. If downstream projects want to use the old type, they should define it.
This obviously requires a major version bump and the release notes should be clear about breaking changes.
Should be closed by #148. At least in #146 it was confirmed to be fixed.
@xiaoyeli Picking up Christian's proposal: May you consider releasing a SuperLU 6.1.0? The release notes should include the breaking change and how to set the flag for backwards compatibility?
Picking up Christian's proposal: May you consider releasing a SuperLU 6.1.0?
Just wanted to make clear that this is NOT my proposal. Incompatible API changes => major version update.
I do need to put up a release. But I don't think it's a major version, i.e., people can still use 'complex'. I think 6.1.0 is good.
I released a new version 7.0.0
This
https://github.com/xiaoyeli/superlu/commit/90ee45dc836d8f4ff967cad4aa2821809b12fdc9#diff-862af30d14f5c76994c21cdb32acbba6da4cb1cd82f26144e417042f742608b2
completely defeats the purpose of https://github.com/xiaoyeli/superlu/pull/116
Please revert. It doesn't make any sense to have
#define complex singlecomplex
for "backward compatibility". There is no more use ofcomplex
anywhere in the SuperLU code since the PR was merged.