complex problems

[wo80]

This

90ee45d#diff-862af30d14f5c76994c21cdb32acbba6da4cb1cd82f26144e417042f742608b2

completely defeats the purpose of #116

Please revert. It doesn't make any sense to have #define complex singlecomplex for "backward compatibility". There is no more use of complex anywhere in the SuperLU code since the PR was merged.

[gruenich]

@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.

[wo80]

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.

[gruenich]

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?

[wo80]

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.

[xiaoyeli]

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.

[xiaoyeli]

I released a new version 7.0.0