Consider shorter release schedules

[cool-RR]

Hey,

One thing I noticed about VisiData is that there's a long interval of time between one release to the next. One consequence of that is that I often don't bother to report bugs. For example, today this happened:

Traceback (most recent call last):
  File "/home/ramrachum/.local/lib/python3.12/site-packages/visidata/sidebar.py", line 115, in drawSidebar
    sidebar, title = sheet.help_sidebars[vd.disp_help%len(sheet.help_sidebars)]()
ZeroDivisionError: integer modulo by zero

Having to find whether the bug still happens in the most recent version is just not worth the hassle. (Especially for this one which I'm not sure how to reproduce.)

[midichef]

I'd recommend you run the latest develop version and upgrade it often, if you can. Your feedback on bugs is valuable. I'd hate to miss out on that.

The particular sidebar bug you mention here was reported in November, fixed in December, and merged into develop last week: #2601. As a heavy user of graphs, you'll probably appreciate develop even more since it fixes a bug in graphing that I introduced into v3.1.1: #2674.

[cool-RR]

I'm afraid that's too bleeding-edge for me. I don't want to be dealing with bugs too often.

[frosencrantz]

@cool-RR. Occasionally develop is broken for me, but I stay close to the latest version of develop, and it usually works. When the breakage is bad enough, I go back to a version that works, and report the issue. It can be frustrating fighting VisiData when you have work to do.

Recently develop is getting mostly fixes from @midichef (thank you!) that have been stable. Those changes go through code review and CI builds before being included.

We've had some discussion of how stable develop should be #1439, .

What is the shape of your reluctance to run develop? Are you ok installing from Github? If you could install from a develop version that passes tests would that be useful to you and would you be willing to run from such a version of develop?

I've felt that if we used the actions to automatically tag the commits that passed tests that might be a reasonable way to have an automated&frequent&stable update. The tests are not exhaustive so breakages can still get through.

The current release process is a manual, thorough, multi-step process (https://github.com/saulpw/visidata/blob/develop/dev/checklists/release.md & https://github.com/saulpw/visidata/blob/develop/dev/checklists/manual-tests.md) that takes @anjakefala's time. Anja has mentioned that parts of the release process are drudgery. Unless Anja or someone else wants to do it, more frequent releases are not going to happen.

[cool-RR]

I see, thank you.

What is the shape of your reluctance to run develop?

I'm not sure how to answer this question, I'm just afraid there'll be bugs and I have to spend time on them.

Are you ok installing from Github?

Yes, that's not the issue

If you could install from a develop version that passes tests would that be useful to you and would you be willing to run from such a version of develop?

I thought that all commits on develop passed the tests... No, having the code pass the tests is not enough for me. I want to use a version that I know many other people are using. I want any problem that I have to be a problem that at least 100 other people are having.

The current release process is a manual, thorough, multi-step process (https://github.com/saulpw/visidata/blob/develop/dev/checklists/release.md & https://github.com/saulpw/visidata/blob/develop/dev/checklists/manual-tests.md) that takes @anjakefala's time. Anja has mentioned that parts of the release process are drudgery. Unless Anja or someone else wants to do it, more frequent releases are not going to happen.

I see. Maybe a solution would be a middle ground, e.g. a release that does not involve making Conda/homebrew/Debian releases etc. So a little similar to what you suggest, but just having that code pass tests is not enough. It should be a version that I know many other people are using.

[frosencrantz]

I know Saul use to track usage by version on http://visidata.org/, and made it available via a URL. I lost the URL.

In another thread you mention using uv, given the simplicity and speed of using uv, would you be more willing to use develop?

Maybe latest passing tests tag, and users using "uv/pipx" would give sufficient eyeballs you want. It is helpful to have more people using the code be able to report bugs.

[cool-RR]

In another thread you mention using uv, given the simplicity and speed of using uv, would you be more willing to use develop?

Maybe latest passing tests tag, and users using "uv/pipx" would give sufficient eyeballs you want. It is helpful to have more people using the code be able to report bugs.

The installation part isn't the problem. The problem is that the commits to develop are too frequent for this purpose, approximately once in 1-2 days. In contrast, the frequency of PyPI releases are once in 2-4 months. I would be satisfied with a frequency between 2-4 weeks. That gives me reasonable assurance that other people are also dealing with the same problems I am, while I'm still enjoying new developments.

Also, if it wasn't clear: I accept that this is not going to happen because no one is volunteering to do this work, and I'm grateful for everyone's work on VisiData.

[saulpw]

We aim to release twice a year. If we were doing more active development I could see releasing 3-4 times a year. More than that isn't tenable unless VisiData becomes a primary job for one of us. Release quality is important and it takes a couple months for a release to 'settle', for enough people to be using it.

I know Saul use to track usage by version on http://visidata.org/, and made it available via a URL. I lost the URL.

The url is linked at https://www.visidata.org/privacy, if ever you can't find it.