Improve type inference of MixtureModel

[devmotion]

Fixes #1307 (or at least type inference of the functions that are mentioned in the issue, there might be some additional problems not covered by the tests).

The main issue was that the prior field is not concretely typed (Categorical{CT} is not a concrete type) and some hardcoded Float64 that broke type inference with dual numbers.

[devmotion]

What is the convention in Distributions - is the different type parameter of MixtureModel considered a breaking change?

[andreasnoack]

Yes

[devmotion]

OK, I updated the version number.

[devmotion]

But now tests fail since there exists no version of HypothesisTests that is compatible with Distributions 0.25 🤔

[devmotion]

I opened a PR that removes the test dependency on HypothesisTests to fix these test failures: #1311

[codecov-commenter]

Codecov Report

Merging #1308 (d51a7a6) into master (5604316) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1308      +/-   ##
==========================================
- Coverage   81.58%   81.48%   -0.11%     
==========================================
  Files         115      115              
  Lines        6659     6623      -36     
==========================================
- Hits         5433     5397      -36     
  Misses       1226     1226              

Impacted Files	Coverage Δ
src/mixtures/mixturemodel.jl	68.11% <100.00%> (-4.73%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5604316...d51a7a6. Read the comment docs.

[andreasnoack]

These are some nice simplifications. We'd have to bump the minor version to avoid breakage.

[andreasnoack]

Yes

[matbesancon]

@devmotion I think we should merge this, but merge any additional breaking change before tagging a new version

[matbesancon]

Following a conversation re-started by @StefanKarpinski, we should probably then tag a 1.0

[devmotion]

Following a conversation re-started by @StefanKarpinski, we should probably then tag a 1.0

I am not opposed to tagging a 1.0, but it wouldn't avoid the problem for downstream packages caused by breaking changes - we just have to bump the major version instead of the minor version.

[devmotion]

any additional breaking change before tagging a new version

What other breaking changes are ready to be merged and released? Maybe #1286, or at least the bugfixes therein that could be extracted?

[matbesancon]

#1286 is not breaking is it?

[devmotion]

It changes the type of LocationScale, so it is breaking in the same way as this PR.

[devmotion]

I guess it would also be a good opportunity to remove the deprecations in the upcoming breaking releases that have existed for quite some time.

[devmotion]

How should we proceed? Merge #1286 and this PR and then tag 0.25?

[matbesancon]

I would prefer keeping the deprecations and removing them when tagging 1.0, so yes let's go with these two PRs

[matbesancon]

@devmotion can you merge master into your branch before we merge?

[devmotion]

Done 🙂