search

JuliaDSP / Wavelets.jl

A Julia package for fast discrete wavelet transforms and utilities
Other
184 stars 30 forks source link

update package versions #63

Closed JeffFessler closed 3 years ago

JeffFessler commented 3 years ago

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 commented 3 years ago

Coverage Status

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

JeffFessler commented 3 years ago

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: https://github.com/JuliaDSP/Wavelets.jl/commit/c6a2b42e630d7d777fc0b02a8c34e5a220b87704 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 commented 3 years ago

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

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:

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

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

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 commented 3 years ago

@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 commented 3 years ago

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

gummif commented 3 years ago

Thanks for that. Looks good to me.