update package versions

[JeffFessler]

The main reason for this PR is to verify that Wavelets will work with the latest version of SpecialFunctions.
Currently the Project.toml is pinned to old versions that causes issues for me in other packages.
I don't really expect this PR to be accepted "as is" because you might want to continue to support old versions too, but it would be very helpful to at least get SpecialFunctions version updated.
(CompatHelper is helpful for this purpose BTW. I could make a PR for that github action if you want.)

[coveralls]

Coverage increased (+0.09%) to 90.374% when pulling e565012 on JeffFessler:master into d337df4 on JuliaDSP:master.

[JeffFessler]

Hi @johnnychen94, thanks for helping out with this. I am fine with all your suggestions if they can be accepted by the owners of Wavelets.jl. I have been having annoying package versioning issues and Julia keeps complaining specifically about Wavelets.jl and its restriction to old versions of SpecialFunctions. The only quick solution I could devise was to fork it and then point MIRT to this forked version.
I left a comment on one of the commits about this:
c6a2b42
but maybe I should have submitted an Issue instead?
What do you think is the best way forward?

A general question about the process here. You are recommending that the Project.toml file list many old versions of packages, but as far as I can tell the CI only tests the latest version. So how we know it is valid to list all those old versions as being compatible? Thanks!

[johnnychen94]

but as far as I can tell the CI only tests the latest version. So how we know it is valid to list all those old versions as being compatible?

Generally, we should keep backward-compatibility as much as possible, and we avoid introducing breaking changes to downstream packages. We should do this because downstream packages/users don't need to change their codes if we do so; the less human efforts involved, the better. We don't test all possible versions; we don't have enough CI resources for this and we don't yet have the utils to cover it. Semantic Versioning(SemVer) is a rule to help us reach the "same" status while requiring less CI coverage.

Let's first discuss what should we do when there're new upstream versions.

As a package maintainer, say, of Wavelets.jl, he/she should be aware of at least the release notes of upstream packages(e.g., SpecialFunctions) and judge/evaluate if the upstream changes will affect Wavelets.jl.

It can be irrelevant upstream changes. Non-breaking changes are definitely irrelevant, breaking changes may or may not be related. If Wavelets.jl is unrelated to upstream changes, then we could safely tag the new version as compatible. Note that old versions are still working here, so there's no need to drop the compatibility here.

It can also be relevant upstream changes. Relevant changes can be upstream API rename, return value changes, or other more complex cases. As a maintainer, he/she should decide

• if it's okay to absorb the changes as compatibility patches inside Wavelets.jl, or
• propagate the breaking changes to downstream packages or end-users.

The ideal choice is to absorb all changes inside Wavelets.jl because by doing this, old user codes still works. However, from cases to cases, it is not always practical to do this. It's the maintainers' responsibility to make tradeoffs here.

Now, let's take SpecialFunctions as an example. Here's what we already know:

• (1) The current version of Wavelets is compatible with SpecialFunctions = 0.7.1, 0.8, 0.9, 0.10.
• (2) The current version of Wavelets is compatible with SpecialFunctions@1.2.1

SemVer is useful because we can approximately infer compatibility from it. According to SemVer, patch versions are backward-compatible and have no new functionalities. Hence

• (3) The current version of Wavelets is compatible with SpecialFunctions@1.2.z

The next question is: do we need new functionalities introduced in SpecialFunctions@1? By revisiting the commit history of Wavelets.jl and the release notes of SpecialFunctions since SpecialFunctions@0.10(since Wavelets works nicely with SpecialFunctions@0.10), we know that we don't. From this, we know

• (4) The current version of Wavelets is compatible with SpecialFunctions@1.y.z

Note that SemVer is not the philosophers‘ stone, it requires everyone's awareness and efforts in the ecosystem to make the conclusion (3)/(4) convincing. When compatibility bugs occur, the maintainer of Wavelets.jl should check which part of the entire dependency chain doesn't follow the SemVer, and submit a patch or file an issue to appropriate places.

---

As a side note, SpecialFunctions = "1" means all versions in [1.0.0, 2.0.0) are compatible, and SpecialFunctions = "0.9" means all versions in [0.9.0, 0.10,0) are compatible. This is because all 0.y.z versions should be considered unstable. See also Version specifier format

[JeffFessler]

@johnnychen94 thanks for the detailed explanation. I have accepted all your suggestions. Now I hope that the Wavelets package managers will accept this PR so that compatibility with recent SpecialFunctions is supported!

[JeffFessler]

Addresses #64.
Also fixes TagBot to be event driven instead of crontab; see https://github.com/JuliaRegistries/TagBot

[gummif]

Thanks for that. Looks good to me.