Release of LCOV >2.3 (was: 2.4)?

[hartwork]

Hi @henry2cox,

I noticed the version bump to 2.4 in b1a5332. I would welcome a new release to allow to cleanly flush recent fixes to end users, e.g. users of Gentoo Linux in my case. Is there a known timeline/ETA for a release of LCOV 2.4? Thanks!

Best, Sebastian

[henry2cox]

Yeah - I bumped the default number - mainly because I forgot to do it earlier :-)
We sometimes see bug reports listing a version number from somebody's build (rather than a 'release') - and I wanted it to be clearer, when that was happening.

With respect to a new lcov release: there are only 2 bug fixes since the last release a few weeks ago, one of which is easy to work around (tempdir in lcov --capture), and one which is not but seems uncommon (spaces in filenames).
I typically wait at least a few months and/or for some moderately useful new features or bug fixes. Not sure we have reached the threshold yet.

I guess that the upshot is that I'm happy to make another release if there is a demand for it - but I will likely wait a bit if left to my own devices.
Given the relatively small changes since lcov/2.3, a release would likely be called 2.3.1 - to indicate the minor nature of the change.

What do you think? What does everybody think?

[hartwork]

Hi @henry2cox!

Yeah - I bumped the default number - mainly because I forgot to do it earlier :-) We sometimes see bug reports listing a version number from somebody's build (rather than a 'release') - and I wanted it to be clearer, when that was happening.

Interesting, I sort of always considered "too low" and "too high" of a version to be equally wrong for any non-tag Git commit, but maybe bumping right after release has slightly less potential of mistaking near-present or present for the past. I think I will stick to bumping at release in my projects for now: it feels more natural and the difference seems rather minor.

With respect to a new lcov release: there are only 2 bug fixes since the last release a few weeks ago, one of which is easy to work around (tempdir in lcov --capture), and one which is not but seems uncommon (spaces in filenames). I typically wait at least a few months and/or for some moderately useful new features or bug fixes. Not sure we have reached the threshold yet.

I'll just braindump here, I'm not intending to be pushy or critical here, I hope my words hit the right tone:
One of the fixes would allow me to simplify packaging and to have interested users run the full test suite with an actual chance of zero failures — it would allow me to get rid of https://github.com/gentoo/gentoo/blob/28fb4f5fbcb89780500d09ed5e78eb46f276f0e7/dev-util/lcov/lcov-2.3.ebuild#L65-L76 . I dared to ask for a release because the cost of doing a release of LCOV seemed rather low from the outside — I might be missing extra steps though, I don't know — and the cheaper releasing is, the more often a project would ideally flush bugfixes to their users in my view, e.g. I just did release https://github.com/hartwork/grub2-theme-preview/releases/tag/2.9.1 a few days ago for a single bugfix that only affects users of Arch and its derivatives because it helps their packaging, off-distro PyPI end users and is reasonably cheap to do for me. I understand that there is no security fix and no showstopper bugfix in the mix with LCOV >=2.3 yet, so I understand that urgency is not high.

I guess that the upshot is that I'm happy to make another release if there is a demand for it - but I will likely wait a bit if left to my own devices. Given the relatively small changes since lcov/2.3, a release would likely be called 2.3.1 - to indicate the minor nature of the change.

The precise version number is the least of my concern in our case. If you do semver — great 👍