Release more often?

[ktbarrett]

The v12_0 was the last release and it is 2.5+ years old at this point. master includes a number of bugfixes, bugfixes that remain unresolved in OSes that package iverilog because they aren't in a release yet. Many projects, even rather slow ones, tend to do at least one release a year, or even two. Are releases very difficult or is there something preventing doing a minor version release once or twice a year?

[martinwhitaker]

See also discussion #1058. I have always been in favour of more frequent releases, but I can never persuade the other Icarus developers.

Minor releases are problematic because they would require bug fixes to be back-ported to the stable branch. I used to do that as a matter of course for all bugs I fixed that didn't require an API change, but the changes to the test suite broke my flow, so I gave up on that.

[caryr]

I think we would all like to release more often! From my current perspective I have a couple fixes in flight, but have not had time to work on finishing them. I tend to favor a release around the end of the year since I often have some time off and can finish up what I'm working on and get ready for a release, but it's a fairly narrow window.

I think part of the slowness is also related to our long term stability in the development branch and then if you want the latest bug fixes/features you just need to compile your own from the development branch and if people are doing that it seems to take off some of the pressure to actually perform a release? When I was actively using Icarus for real work I always used the development branch because of the fixes and newer functionality and that has likely lowered my prioritization of releases.

I have a few things I would like to see in the next release so maybe this all needs to go into #1058 to give better focus and clarity regarding what will and will not be in the next release.

[caryr]

FYI my general goal for a release is to fix as many of the bugs as we can, but this last year it has been harder to keep up since we have had both fuzzing and frame work people submitting corner case bugs that while valid may not be encountered by a normal user writing code or they would just work around the current limitation.

[ktbarrett]

I think maybe a change in how releases are thought about would help. Make releasing the priority and orient the rest of the decisions around that. For example:

• We release twice a year from the master branch.
• If it changes the API, we inc the major version.
• If not, we inc the minor version.
• We don't maintain version branches, the next release will be soon enough.
• We don't wait for the code to be perfect before release, bugs can wait until the next release, which will be soon enough.

If we expect most people are just running off of master anyways to avoid old releases, then worrying about what goes into a release is kinda pointless.

[ktbarrett]

That's how Python and cocotb are developed (well 2.0 was special since we wanted to get all the API breaks in at once). We try to do minor releases twice a year, get in what we can in that period, and release whenever we have time. We only support doing bugfixes on the last release to keep it working while we develop the new version and the release branches tend not to get very big because of how often we release.

[caryr]

Yes, things are clearly not working as we would like.

FYI one of my pending changes is for cocotb #1038

[ktbarrett]

Ah yeah. That would be nice. We do have a way around it that's basically discovering everything greedily using iteration. As long as your design is small, it's not an issue. Also ALL VHPI simulators have the same issue (besides NVC). I don't think it needs to prevent a release.

[strophy]

We're currently blocked over at Alpine Linux from updating packages like yosys that depend on iverilog to run tests. Developers have started to assume the dependency is running off master, causing tests to fail because we can only package tags or releases:

Test: test_parse2synthtrans -> ERROR!
Note: Make sure that 'iverilog' is an up-to-date git checkout of Icarus Verilog.
make[1]: *** [../tools/autotest.mk:10: test_parse2synthtrans.v] Error 1
make[1]: *** Waiting for unfinished jobs....
Checking true.aag.
[8]Test: issue00335 -> ERROR!
Note: Make sure that 'iverilog' is an up-to-date git checkout of Icarus Verilog.
make[1]: *** [../tools/autotest.mk:10: issue00335.v] Error 1
...

Packaging from master isn't practical, if master generally works fine would it be possible to just add a tag to a known working commit? What does the tag s20250103 mean, can I use this?

Would love to see some movement on #1058 to unblock updates to these other packages, thanks! 😃

[martinwhitaker]

The tag s20250103 means a development (i.e. master branch) snapshot taken on the 3rd January 2025, so yes, that is explicitly tagging a known working commit. In general we always run the full test suite locally before pushing to the master branch, so it is very rare for it to be broken.

[martinwhitaker]

I have created a new development snapshot and published it on GitHub. I still hope we can release v13 soon.

[caryr]

We have resumed discussions in #1058 so comment there regarding the pending release.