Re: [RFC] Introduce semantic versioning 2.0.0 to FreeBSD releases

On Wednesday, February 25th, 2026 at 8:13 AM, Dag-Erling Smørgrav <[email protected]> wrote:

> Minsoo Choo <[email protected]> writes:
> > FreeBSD's git repository reserves semantic versioning style patch
> > version (aka third version) in git tags but it has been unused for a
> > long time (e.g. 15.0.0-p1).  This results in having two patch version
> > placeholders where one is unused and might​​ cause confusions for some
> > newcomers.  The last git tag that contains patch version in semantic
> > versioning format is 5.2.1.  After that, tags for both patch version
> > placeholders are missing until 13.4.0-p2 and 14.1.0-p6 (re@, why are
> > we missing these tags?  Can we recover them?), and we cannot track
> > what happened in the past.
> 
> We used to have third-level versions back in the 1.x and 2.x days; for
> instance, the first FreeBSD version I ever installed was 2.0.5, and I've
> used FreeBSD continuously since 2.2.1 or 2.2.2 (I forget which of these
> two made the switch from /etc/sysconfig to /etc/rc.conf).
> 
> Since 3.0, we've only had a third-level version four times (3.5.1,
> 4.1.1, 4.6.2¹, 5.2.1), all because a serious issue was discovered in a
> release before the CDs went to press.  Since the project is no longer
> associated with a business that publishes releases on physical media,
> this is unlikely to ever happen again.
> 
> Furthermore, since the introduction of freebsd-update in 2006, our
> release and update processes have, to a large degree, been constrained
> by the capabilities of the tools used by re@ and so@.
> 
> All in all, I think it's safe to assume that patch levels have
> completely replaced the third-level version number.
> 
> > Thus, I propose using semantic versioning 2.0.0 [1] starting from
> > FreeBSD 16.  Major and minor versions will have the same roles as
> > before.  For patch versions, I propose including bug fixes as well as
> > security patches.  For bugs, I mean existing things that do not
> > produce expected behaviour that has "Fixes: " metadata in git commit
> > message.
> 
> What you are proposing is effectively what we've already been doing for
> the last 20 years.  Instead of a third-level version number we have a
> patch level, which is incremented for every batch of SAs and ENs we
> release.  So I'm not sure what you're asking for.

You're right. I was confused here.
 
> The only issue I see with our current practice is that we still tag
> release/x.y.0-pz instead of either release/x.y-pz or release/x.y.z.  If
> that's what bothers you, we can trivially create retroactive aliases for
> those tags.

We don't need to create alias for previous releases although missing tags for previous patch releases should be created as I mentioned above. What I'm suggesting here is sticking with x.y.z and abandoning the -pX versioning starting from FreeBSD 16. Another benefit I find is that third-party websites and applications can manage FreeBSD versions through widely supported packages like semver [1] without creating custom version parser.

> But I would strongly advise you to check the NIST NVD and
> make sure that whatever change you propose will not result in a
> discontinuity in CPEs.

Thanks for the info. I'll check that.

> 
> ¹ 4.6.1 was tagged, but not officially released.
> 
> DES
> --
> Dag-Erling Smørgrav - [email protected]
> 

[1] https://www.npmjs.com/package/semver

--
Minsoo Choo