I wrote a package WringTwistree, which is a cipher and hash function. When I wrote it, I didn’t know how to use startup.jl, so it depends on Debugger, ProfileView, and Revise, which it doesn’t need but I found useful when developing it. I just found a bug: if the key is a single byte, it throws an error. WringTwistree is currently at version 1.0.0. If I just fix the bug (which I’m fairly sure is trivial, but I will have to check it against the Rust and Haskell implementations), I can bump it to 1.0.1. But if I fix the bug and remove the dependencies, do I have to bump the second number?
1 Like
You can freely remove dependencies that don’t affect the public API of your package. Version 1.0.1 is fine for the bug fix.
3 Likes
Going through the exported functions, I found some that are used only for testing, such as one that repeatedly rotates a block of bytes by its bitcount until it repeats. If I deprecate them, I have to bump it to 1.1.0, right?
From semver.org:
How should I handle deprecating functionality?
Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.
The unspoken suggestion there is to be careful with what you put in the API because you don’t want accumulated deprecations or frequent major releases.
Was it documented? If not, you can remove it freely.