Backwards incompatible changes starting in v0.2.0

[colinmcintosh]

Hi, it looks like starting in v0.2.0 there are backwards incompatible changes to exported function signatures, specifically the Backoff constructors have the error return value removed resulting in code changes being required anywhere these are used. I do see this noted in the release notes for v0.2.0. While this isn't necessarily against the guidelines for Golang projects given the major version is v0 it isn't great to have to go through and make updates to projects using this library after the previous API had been stable for about 18 months.

Are there plans to bump this project to v1 and consider the API stable?

Thank you for your time and effort on this library!

[sethvargo]

Hi @colinmcintosh

Thank you for opening an issue. Any breaking changes and high-level release notes are always included with each release. For example, the change you highlighted was called out in the v0.2.0 release notes.

If you don't need the changes, don't update 😄. It seems a bit odd from a software supply chain perspective to blindly pull in updates without reviewing the release notes and changes.

I'm not yet ready to cut a v1 and call the API stable.

[colinmcintosh]

Thanks for the answer to my question. I've closed the issue.

It seems a bit odd from a software supply chain perspective to blindly pull in updates without reviewing the release notes and changes.

One thing I'll note with this is that it's tough battle to fight between trying to proactively keep dependencies up-to-date and also maintaining awareness of every change noted in release notes to determine what changes actually need to be pulled in. When you have many projects with many dependencies it is non-trivial to understand the release notes for every release that's happened since the last time dependencies were updated (granted, go-retry has not had a significant number of releases since v0.1.0).

I generally agree that if you don't need the changes you don't need to update but, from my experience, that kind of reactive dependency updating also leaves you open to further issues down the line when a dependency has fallen way behind the curve and requires much more effort to bring up-to-date. I find it's generally less cumulative effort to continually and incrementally update dependencies when possible, which is how I encountered this change. 🙂

[github-actions]

This issue has been automatically locked since there has not been any
recent activity after it was closed. Please open a new issue for
related bugs.