Monthly Patch Updates?

[kevinmatthes]

As the question on a new version release came up in #61, I had the idea to publish updates at least monthly to mirror the latest dependency updates' effects. The updates would just push new dependency versions to the registry in order to prevent issues arising from too old versions of any called libraries. In terms of SemVer, these updates would be patches. At option, some sort of automation might be possible, as well, but I would prefer to generate and publish them manually in order to be able to also include certain new features and / or internal refactorings into the new versions without having to mind any fixed schedule.

[0323pin]

@kevinmatthes I haven't voted because, it depends.

If the dependency updates trigger a version bump, than I'm ok. But, if these are just pushed to crates.io without version bump, that's a big no. We build offline and if, this happens checksums change and builds break.

Also, if this is done, I would appreciate a clear indication of MSRV.

If the above applies, YES is my vote.

[kevinmatthes]

Thank you for your feedback!

The generated releases shall receive a new version number; my suggestion is to increment the patch level. Furthermore, I also would appreciate having the MSRV pinned to a fixed version -- but this decision is up to @ttytm.

I can prepare everything to implement both aspects as I already use something similar in another Rust repository.

[kevinmatthes]

@0323pin

I just submitted an initial suggestion for the MSRV setup; #249.

[ttytm]

Thanks for the suggestion. This should be done in some way when having the automatic updates.
As the automated updates might mask the necessity of a version bump when there was a vulnerability or security fix in a dependency that affect wthrr since it's last version (without automatic updates, GitHubs built-in feature could alert maintainers in case of a vulnerability in a dependency so that an update and release can be made if needed).

After the introduction of automatic dependency updates, my personal assessment so far is that I'm not convinced by them.
Imho, the benefits are so marginal that the downsides will outweigh and making it a liability for a lot of projects. They pollute the commit log. I find them annoying in most public repositories, as do most developers I know. As mentioned above, they might mask security updates that should result in a version bump.

Now, directly related to the topic of this discussion, I also don't want to throw monthly updates at users just to make some dependency updates that don't bring noticeable benefits or fixes to the crate.

One option would be to deactivate automatic updates and revert to using cargo update before releasing a new version.
But instead of deactivating them I thought the best solution would be to further fine tune them to keep the benefits while reducing noise and maintenance.

This is what I thought of:

• Reducing renovates PR frequency to monthly
• If possible, keep weekly audits for security fixes, make a PR if such where made
• Implement renovates noise reduction strategies, like grouping
• Automated version bumps and releases if the vulnerability was fixed in a dependency since the last release (this would require comparison with the dependencies of the last tag)
• Automatic patch version releases if the last release is older than 60 days

[0323pin]

I like this. A tight release schedule also increases the burden on package maintainers. This is where I'm coming from 😉