Release 0.8

[martinholters]

I've skimmed through the open issues and PRs to try and find anything that would require a breaking change because now - working towards 0.8 - would be the time to set them in motion. This resulted in a bunch of deprecation PRs which I've added to the 0.8 milestone. Then there is also #186, where I'd also expect a (somewhat) breaking change necessary to fix it, but I'm not sure what a short-term, preparatory first-step would be (if there is one). I've nevertheless added it to the milestone so as not to forget it.

I'd like to invite feedback on what we should do about #186 for 0.8 and whether I've missed anything that should be added to the milestone.

Pinging @wheeheee and @ViralBShah due to their recent activity here, but not to exclude anyone else from chiming in.

[wheeheee]

About potentially breaking changes: maybe a decision on #372?
For #186 I would say M*N is more intuitive. Also if each value is a time average it seems to me that it wouldn't really be extrapolating beyond the end of the signal? And, if we upsample by an integer then down sample by the reciprocal, it's nice to get the same length back.

Lastly, I think that's the default Matlab behaviour, so...

[martinholters]

Re. #186, I agree that M*N is the way to go, the questions are:

• Can this be solved in a reasonable time-frame for 0.8? Or would that delay 0.8 unreasonably? (I have only glanced at the implementation and was a bit scared by the complexity, by maybe it's not that bad upon closer inspection.)
• Should we just change the output-length unconditionally or make the new behavior opt-in, at least for a transition period? Probably with a deprecation warning similar to the one in Deprecate welch_pgram without explicitly given window #581, i.e. a la "warning, default is going to change, please make an explicit choice for now".
• In case the answers are "no" and "yes", is there anything we can do for 0.8 already to prepare that deprecation/transition? ("Please opt in to the weird behavior now, as in the future, there might be a more reasonable alternative that should become the default then." I'm not convinced.)

(But let's keep the technical details to #186 and only discuss timing/release strategy here.)

Re. #372, that indeed looks like it might require a breaking change, but at least to me, the path forward is even less clear than for #186, so my gut reaction is to postpone that to 0.9 to avoid blocking 0.8 indefinitely. Maybe I come to another conclusion after pondering it for a bit. Either way, I'll add it to the milestone so we don't forget.

[wheeheee]

• Can't tell, I found the code hard to understand the last time I tried to look into the bounds error, but on a wild guess, no. If the problem looks intractable to you, IMO it's better to push it to the next major release.
• I feel that, since it looks like a bug (?), yeah it could be warranted to forgo deprecation and go for an unconditional change. I also don't see the point of giving a depwarn about a fix that has not materialized yet.

[martinholters]

So as far as I am aware, #603 is the last to-do item before we can tag. While #603 has been approved and is ready to be merged, it might be somewhat controversial and I'd like to wait one or two days for people to chime in in case they consider it problematic.

In case #603 goes through, I'd than tag v0.8 shortly afterwards. Or are there any objections? Anything else still missing?

[martinholters]

Finally, it's done.