What would be the ideal release cadence for bat?

[Enselic]

In your opinion, what would be the ideal release cadence for bat? In other words, how frequently would you like to see releases of bat?

Feel free to motivate your answer, and also to say if you are a bat user, a bat package maintainer, or something else.

[SuperFola]

I don't think any open-source project should stick to a release schedule, but rather publish an update whenever something major/minor needs to change. For patches I think it should / could be up to the end-user to download and compile it if they really want it?

[Enselic]

Requiring users to make their own judgment call on what patches to include or not puts a big burden on them. That means the project in question will get fewer users. Which in turn means fewer contributors. Which goes against the desire of many open source projects.

bat has the pleasure of having a steady stream of contributions coming in, so we probably could make a release every [redacted to not skew poll] with something new. The risk with waiting for "just one more contribution" before making a release is that a release never gets made, which is a good way to stop a project from being fun to work on. A time based release strategy is used successfully by many high profile open source projects. Rust itself to give just one example.

[SuperFola]

To me, patches are quite small and often it won't change the life of the end user, only of some developers or users with very specific needs, that's why I think they can download / build / install the patches without a release being made. I understand your point of view, specifically on the risk of "one more contribution", but I tend to disagree a bit about the "time based release strategy -> keep it fun to work on". Both sides are valid, I just wanted to point out that forcing yourself / the dev team to stick to a release schedule could be a burden in the long run!

[anurag-roy]

Wish we had gone forward with this, nothing too strict, maybe a loose monthly release schedule.

Currently its been close to a year without any new releases, while there have been loads of commits and issue resolutions merged to master. One such example being #2960, it's there in master since Feb, but its not there in the current release of bat.

[timhillgit]

Hi @keith-hall I hope it's okay to tag you in to this discussion. It's been quite a while since the last bat release and I know that there some features that folks would like to use that have been introduced since the last release. Also I believe some distribution methods are having to maintain backported patches. The poll that started this discussion didn't quite have a majority in favor of any one cadence but an overwhelming majority supported 1–3 months.

What do you think about cutting a new release and then beginning regular releases at any cadence between 1 and three months?

[keith-hall]

I think it makes sense to cut a new release :) I'll see what I can do

[keith-hall]

bat v0.25.0 has now been released! 🎊

[timhillgit]

Fantastic news, thank you @keith-hall !

[anurag-roy]

Thank you! @keith-hall

[jacktose]

Since this discussion is still open (and #3088), could we get a v0.25.1 or v0.26.0 release? It's been [checks notes] 319 commits since v0.25.0.

For a user story: I was very confused because #2999 (--strip-ansi) was included in v0.25.0, but c25e005 (add it to the manual) was not. I forked the repo to PR a manual update, only to find the manual source has been updated, but is still incorrect in packaged versions.

[keith-hall]

there are a couple of things I want to have completed before making the next release, but hopefully it will be soon ™️ now: https://github.com/sharkdp/bat/issues?q=is%3Aissue%20state%3Aopen%20milestone%3Av0.26.0

[kenwilliams412]

I think every quarter as it balances timely feature updates and stability without overwhelming users or maintainers.