Why all the tiny releases?

[asmaloney]

Seven releases in the last three days? It looks like there's a release for every commit.

Is something broken in the GitHub actions?

[meatballhat]

@asmaloney This is intentional. More details coming over here 👍🏼

[asmaloney]

OK thank you.

Small stable releases are great, but a release for every commit is painful. Way too much noise, harder to track, and it's distracting.

If this were the only package I were using, maybe it would be fine, but when dealing with dozens or hundreds of dependencies, it's not.

My 2 cents! 😄

[meatballhat]

@asmaloney fwiw it's not release-per-commit but closer to release-per-PR-merged. Better, I hope? 😅

[meatballhat]

@asmaloney ooh also, can you describe your dependency tracking process? Do you have anything like automated go get github.com/urfave/cli/v2@latest going on?

[decentral1se]

but closer to release-per-PR-merged

Sorry but this is still "Way too much noise, harder to track, and it's distracting."

I want stable releases but not ~10 in a week?

[meatballhat]

@decentral1se Right now the priority is to get bug fixes out as soon as possible, which means you're going to see a lot of patch releases. I don't expect this will be the case indefinitely, given we're coming out of a period of work piling up.

That being said, can you help me with more details behind what's noisy, harder to track, and distracting about this?

[decentral1se]

Can appreciate you're diving in to a backlog, thank you very much!

We had 10 releases in a week. If you can't understand that as being hard to track, there's not much more I can do for you.

2.4.1 -> 2.4.8 should've/could've been 1 release.

I don't need research-backed release engineering, just a good call of judgement for a new release.

Thank again, that is 2 cents.

[meatballhat]

@decentral1se This is volunteer labor for all of us, and at least in my case I don't know exactly when I'll next have a chunk of time to devote to this work. If I'd known I would have the opportunity to release all of v2.4.1 through v2.4.8, maybe I would have batched releases together differently 🤷🏼.

We had 10 releases in a week. If you can't understand that as being hard to track, there's not much more I can do for you.

Who is tracking what in this case? It's not obvious to me how the releases in question came to be a source of stress for you.

I don't need research-backed release engineering, just a good call of judgement for a new release.

A judgement call informed by what?

[piepmatz]

Example of noise: We have several repositories using this package. Their dependencies are kept up to date with https://github.com/renovatebot/renovate. When there is a newer release, renovate will create one PR per repository.
This quickly leads to lots of PRs. Which is fine, that's what we have renovate for.

But when this happens again for cli after just a couple of days, I tend to start ignoring those PRs because there will be new ones shortly after anyway, so why merge them at all.

[decentral1se]

Who is tracking what in this case? It's not obvious to me how the releases in question came to be a source of stress for you.

I am a developer of a tool which relies on this package. I am tracking updates for this package. When there is an update, there is work to do for me. If I see a stream of 10 updates, I need to review them all, see what is going on, make a decision how I want to do my upgrade work. That's more work than usual.

A judgement call informed by what?

Well it's up to the maintainer (you?) when you feel like it, usually. Depends on the person & changes, right?

[meatballhat]

Example of noise: We have several repositories using this package. Their dependencies are kept up to date with https://github.com/renovatebot/renovate. When there is a newer release, renovate will create one PR per repository.
This quickly leads to lots of PRs. Which is fine, that's what we have renovate for.

But when this happens again for cli after just a couple of days, I tend to start ignoring those PRs because there will be new ones shortly after anyway, so why merge them at all.

TIL that renovate is a thing! 🎉 Thank you, @piepmatz

A pull request for every patch release sounds like no fun at all! I'm sorry you've had to deal with this. I looked a bit at the renovate docs and realized there's more there than I can understand in a few minutes. Do you know if there's a way to configure renovate to check based on a time interval or some other way to sidestep the PR-per-release behavior?

[meatballhat]

Who is tracking what in this case? It's not obvious to me how the releases in question came to be a source of stress for you.

I am a developer of a tool which relies on this package. I am tracking updates for this package. When there is an update, there is work to do for me. If I see a stream of 10 updates, I need to review them all, see what is going on, make a decision how I want to do my upgrade work. That's more work than usual.

I commend you for how much care you are taking with your dependency ecosystem 👏 🎉

The releases are small in part to help with reviewing like this. If you prefer to review multiple small releases at once, please feel free to do that.

A judgement call informed by what?

Well it's up to the maintainer (you?) when you feel like it, usually. Depends on the person & changes, right?

In my case, my judgement call was informed by unpredictable volunteer labor availability and my desire to prevent situations like we've had in this project in the past where months pass between releases, effectively forcing users of this library to maintain long-lived forks.

[piepmatz]

Do you know if there's a way to configure renovate to check based on a time interval or some other way to sidestep the PR-per-release behavior?

Yes, https://docs.renovatebot.com/noise-reduction/ and especially https://docs.renovatebot.com/noise-reduction/#selective-scheduling. This would work for me if you decide to continue with many small releases.

[meatballhat]

Do you know if there's a way to configure renovate to check based on a time interval or some other way to sidestep the PR-per-release behavior?

Yes, https://docs.renovatebot.com/noise-reduction/ and especially https://docs.renovatebot.com/noise-reduction/#selective-scheduling. This would work for me if you decide to continue with many small releases.

Excellent! If that's available to you, please yes go ahead with the noise-reduction mitigations that work for you. I can't predict exactly what the release frequency will look like given the nature of our volunteer labor pool, but my intention for the near future is to follow this priority list and opportunistically push out patches ASAP.

[xoxys]

While the noise reduction in dependency management tools works in general, it might still be an issue. If someone schedules PR creation on a weekly or monthly basis, how would I notice an important security release?

Yes, I could subscribe to the mailing lists (if available) for every direct and indirect dependency, but that's a nightmare as well. So applying time based schedules might delay security fixes.

Another point is, a lot of people using the "Watch Releases" feature in GH and need to turn it off now because it is flooding notifications.

[dearchap]

I think we are talking about a transient situation here. There have been lots of issues/PRs piled up in the past one year or so with minimal reviews/comments/releases by the original maintainers. We have some new maintainers who have the time to speed up this process so we are willing to knock off PRs asap. Thats why you see this flurry of releases. This is not sustainable in the long term since the maintainers are not available to work on this project 100%. So we see this initial rush of releases and over time you will see the release cadence slow down. Yes its a minor inconvenience but imagine the delight of all those users who posted issues and see fixes drop within a few days rather than months or years !!!!

[abitrolly]

I guess it is possible to regenerate https://github.com/urfave/cli/blob/main/docs/CHANGELOG.md when a new security or a major release is done, but somebody needs to write that automation https://github.com/urfave/cli/blob/main/docs/RELEASING.md

Maybe adopting https://github.com/googleapis/release-please if it is possible to avoid remembering those picky commit comment rules.

[dearchap]

We have a changelog on GitHub directly. Not sure how much work is involved in keeping this file in sync with that

[abitrolly]

@dearchap it is not convenient to page though it, so I was thinking about changelog that groups changes for major releases.