Deprecation removals outside of major version bumps

[LandonTClipp]

Hi, thanks for the wonderful project and the huge amount of time you've spent on it.

Recently, the deprecation of archives.replacements has broken a number of my release pipelines both in public and private repos. I was wondering why these breaking changes are introduced outside of major version bumps? Typically what I have seen projects do is issue a deprecation warning for a feature that will change/be removed in the next major version, but the fact that these incompatible changes break semantic versioning means my builds will start failing everywhere all of a sudden. I do know that the warning was issued for a few months, but I can't realistically be monitoring all the hundreds of projects I use for these warnings. Semantic versioning is supposed to do that job for me. When projects violate this, it becomes a painful maintenance burden. Ideally, I'd only have to worry about deprecation removals if I'm explicitly changing the major version of a dependency.

Let me know your thoughts, thank you!

[caarlos0]

historically goreleaser was 0ver, so goreleaser does not strictly follows semver, especially given its really hard do properly do so in a project this big and with this many dependencies, and, given that major bumps in go are a PITA, v2 will likely happen only when I need to a major rewrite, change the configuration from yaml to something else, or another really big change.

A couple of suggestions:

• lock to a specific minor version (e.g. 1.19.x)
• have a job run goreleaser check every X time... the build will fail if you're using deprecated options

All that being said, sorry for breaking your builds.
I try really hard not do so, leaving the option deprecated for 6+ months, warning in the build log, etc, but I accept it will nevertheless happens sometimes.

[LandonTClipp]

Thanks for the thoughtful response. I understand the pains of managing a project this large with a bunch of complaining customers so you have my sympathies. Perhaps I can share how I personally manage something like this, you can take it or leave it.

In my project https://github.com/vektra/mockery, it also relies on complicated configuration semantics. I've undergone a large change to my config in v2 of the project. While introducing the new config semantics, I explicitly support both the old and the new styles of config. Over time, I accumulate deprecation warnings in v2, both in the docs and through a WARN log message in the code. Once the number of deprecations are large enough, I'll move the project to v3 and remove legacy logic that supported deprecated functions. While bumping the major version is indeed painful, I've found the cadence really only has to be once every 2-3 years (or longer honestly), which is a small price to pay to respect semver.

In my view, it's far preferable for a project to be incredibly slow in removing deprecations than to enthusiastically remove old behavior while violating semver. I know you say historically you followed 0ver, but the 0ver website itself is satire and is meant to highlight the ridiculousness of following that scheme. Semver is really important for stability. Locking the version I guess would work, but it's a suboptimal solution IMO because then upgrades are far more manual, tedious, and error-prone, and we won't get automatic bug fixes.

Just some thoughts. Thanks again.

[caarlos0]

I think your strategy makes sense. I might do something similar.

About 0ver, yes, I know its a satire, just meant to say that for the longest time we didn't had any major releases, and that the deprecation process is from that time - and it made more sense then than it does now.

I'll think about it a bit more, and share/announce what I come up with.

It won't fix what already happened, but will hopefully prevent it from happening again.

Thanks for all the info and thoughtful messages.
Cheers!

[ryancurrah]

It has been a pain point for us as well. A lot of modules we had to fix this week in order to update use latest. We just ended up writing a script and pushing directly to main branch on around 568 repos. Scary but needed to be done.

[caarlos0]

thanks for sharing this @ryancurrah, I'm working on a more formal release cadence proposition and will ping here when I do 🙏

[caarlos0]

FWIW link: https://goreleaser.com/blog/release-cadence/

[decentral1se]

https://goreleaser.com/blog/release-cadence/

[caarlos0]

Thank you, I forgot to update here!