Collection of bug fixes for a potential v4.7.1

[markuspg]

Hi,

this merge request collects fixes from current master for a potential v4.7.1. I'm using this locally for quite a while and thought maybe it might be useful for someone else too. I went through all commits on master since v4.7.0 and cherry-picked anything looking like a fix (but without breaking behaviour).

The only breaking fix I cherry-picked is sim_if: continue after compilation failure if '--keep-compiling' is True.

[LarsAsplund]

I'm a bit hesitant to make an official 4.7.1 with the purpose of avoiding backward breaking features. I don't want to create an expectation that there will be a long-lived 4.x branch that will be maintained in parallel with 5.x. I rather see that people starts using the pre-releases for version 5.0.0 (https://vunit.github.io/installing.html#using-the-python-package-manager) in order to get access to the latest updates. There will be some breaking changes to address but for most project that is not a major effort that needs to be postponed.

[nathanaelhuffman]

To flip this around a bit, it seems like there's appetite for picking up quite a few bugfixes given the length of time since the last stable release. Is there consideration toward making more frequent bugfix releases going forward in the 5.x branches? It would also seem to me that there's no implication that a release now locks the project into supporting more backports to the 4.x branches long-term.

That said, as a long time user I hadn't realized some pre-release versions are available via pip, so that solves my immediate need for a more recent release without making pip point to main, and thanks for referencing it!

[markuspg]

@LarsAsplund I perfectly understand your reasoning. At least speaking for me I wouldn't expect a long-lived 4.x branch. My thought was that in the last one and a half years "all" major bugs in 4.7.0 should be found and fixed on 5.0.0. So 4.7.1 would just end out this branch. For my private programming I love riding bleeding edge, for professional projects I prefer tried and tested code.

I'm not familiar with the codebase, but all fixes seemed trivial to me. Maybe the fix for #742 could be dropped, since this is a breaking one. I also didn't cherry-pick the fix for #1026, because I found it difficult to judge the consequences and the issue seemed quite specific to me (contrary to e.g. the memory leak, which is bothering me ;)).

Maybe I'll give 5.0.0 a shot then too. I started this whole endeavour because I'm hunting down a memory leak - that's why I was on the lookout for a bullet proof VUnit release. Yesterday (using the code from this merge request) I found out that the issue is with GHDL actually (anyone else having issues there?).

Anyhow, thank you for your work on VUnit!

[LarsAsplund]

It feels to me that the "impression of a version number" is creating problems for us:

1. If we spread several breaking updates over several major releases, we are giving the impression of an "immature project". In reality, the number of breaking changes are the same. The breaking changes we have prepared for v5.0.0 are typically small and insignificant to most users or larger but announced for a long time such that users had time to prepare.
2. Pre-releases are considered experimental. In reality, there is no major difference between commits on the main branch between releases and those with a release tag on them. Development is on feature branches and new features are tested before they are merged.
3. Frequent (feature) releases give the impression of an active project so some projects do them at fixed time intervals for that reason although there may be other reasons as well. In reality, it is the pace of commits and the significance of those commits that matters.

Number 1 is the reason for waiting with v5.0.0, but I feel number 2 is a problem as well. Number 3 might be a solution.

What do you think would be the best approach going forward? My goal is that users incorporate new commits into their projects as they appear in the main branch. What are the obstacles preventing that? One obstacle I see is that the users are not in a position where they can decide when tools are updated. There can also be formal processes coming from the safety and security nature of the projects.