Re: git: 32137c41065c - main - sound: Retire the version constants

On 9/26/26 13:37, Jason Harmening wrote:
> I'd definitely agree on getting rid of the min/max/pref distinction and
> just having a single version.
> It's always seemed like a stretch to imagine any dependent module making a
> meaningful distinction between those 3 versions in a way that wouldn't be
> extremely fragile.
> 
> Ideally, some form of module-specific versioning still seems useful for
> addressing scenarios like the mixer_init() case I described above.  Bumping
> the global version for cases like that seems very heavy-handed, though
> maybe it wouldn't be such a big issue in practice, or maybe some of the
> recent suggestions for consolidating those version bumps could be useful in
> cases like this.

We already use __FreeBSD_version to mean there is a KPI or KBI change.  I also
think the recent thread on bumps was a bit exaggerated.

Here's some data vs anecdotal "we bump too much" feelings:

> git log --first-parent -G __FreeBSD_version --format=%cs sys/sys/param.h | uniq -c | head -30
    1 2026-09-14
    1 2026-09-09
    1 2026-09-06
    1 2026-09-05
    1 2026-09-02
    1 2026-08-27
    1 2026-08-12
    1 2026-06-19
    1 2026-04-30
    1 2026-04-25
    1 2026-04-23
    1 2026-04-06
    1 2026-03-21
    1 2026-03-12
    1 2026-02-13
    1 2026-01-25
    1 2026-01-23
    1 2026-01-16
    1 2026-01-13
    1 2025-12-18
    1 2025-12-15
    1 2025-12-09
    1 2025-11-02
    1 2025-10-30
    1 2025-10-21
    1 2025-09-29
    1 2025-09-04
    1 2025-08-18
    1 2025-08-17
    1 2025-08-16

As you can see, we've yet to have multiple bumps on a single day in the past year (which I
agree should be avoided), but bumps are also rather sporadic.  We have a few weeks a year
where they cluster (multiple bumps in a week), but we also have entire months without a
single bump.

-- 
John Baldwin