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

At this point, I don't see the benefit of my proposal. My original intention was to make versioning clear by following __common__ practice in the software world, but we could end up mixing two here due to backward compatibility (and it's a fair point). If that's what's going to happen, we should follow the status quo.

--
Minsoo Choo

On Wednesday, February 25th, 2026 at 4:58 PM, Tomoaki AOKI <[email protected]> wrote:

> On Wed, 25 Feb 2026 20:26:29 +0100
> vermaden <[email protected]> wrote:
> 
> > Hi,
> >
> > I would prefer staying with what we have ... for consistency.
> >
> > All the tools/scripts/everything have already been 'taught' to interpret 14.3-RELEASE-p7 format.
> >
> > Switching *now* after more then 30 years of FreeBSD releases would only cause this: https://xkcd.com/927/
> >
> > No one wants that confusion.
> 
> +1.
> 
> 
> >  ... but I have better idea.
> >
> > We already have these:
> >
> >     % sysctl kern | grep -e kern.osrelease -e kern.version
> >     kern.osrelease: 14.3-RELEASE-p7
> >     kern.version: FreeBSD 14.3-RELEASE-p7 GENERIC
> >
> > Adding additional 'kern.dotrelease' which would be in 0.0.0 format will not hurt anyone - yet you will have your version.
> >
> >     % sysctl kern | grep -e kern.osrelease -e kern.version
> >     kern.osrelease: 14.3-RELEASE-p7
> >     kern.version: FreeBSD 14.3-RELEASE-p7 GENERIC
> >     kern.dotrelease: 14.3.7
> 
> Historically, there were 1.1.5.1, 2.1.6.1 and 2.1.7.1.
> 
>   https://github.com/freebsd/freebsd-src/blob/main/share/misc/bsd-family-tree
> 
> Not sure about 1.1.5.1 (as at the moment I didn't know the exixtence
> of FreeBSD yet), but IIRC, 2.1.6.1 and 2.1.7.1 were something
> like current -p* point releases.
> 
> So, if introducing 2 or more dot format as kern.dotrelease
> sysctl, what I recommend here would be "kern.dotrelease: 14.3.0.7"
> corresponding to "kern.osrelease: 14.3-RELEASE-p7".
> 
> And if there happenes to require any security update breaking
> backward compatibilities next to 14.3-RELEASE-p7, use
> irregular 14.3.1-RELEASE with __FreeBSD_version bump.
> 
> The next patch release for 14.3.1-RELEASE should be
> 14.3.1-RELEASE-p1.
> 
> I think this doesn't hurt current semantics of release tags
> and would be safe for 4 2-dots release.
> (I imagine __FreeBSD_version 1403100 for 14.3.1-RELEASE
> and following point releases. Stable restarts from 1403500
> after 14.3-RELEASE, so using 1403100, 1403200, 1403300 and 1403400
> would be safe.)
> 
> Regards.
> 
> 
> > ... and I would also add '-d' flag for freebsd-version(*) to print FreeBSD version in '0.0.0' format.
> >
> > Regards,
> > vermaden
> >
> >
> >
> > Temat: Re: [RFC] Introduce semantic versioning 2.0.0 to FreeBSD releases
> > Data: 2026-02-25 17:42
> > Nadawca: "Tomek CEDRO" &lt;[email protected]>
> > Adresat: "Minsoo Choo" &lt;[email protected]>;
> > DW: "freebsd-hackers" &lt;[email protected]>;
> >
> > >> On Wed, Feb 25, 2026 at 7:17 AM Minsoo Choo wrote:
> > >> Currently FreeBSD uses a variant of semantic versioning for releases
> > (e.g. 15.0-RELEASE-p1) where backward compatibility can be broken (e.g.
> > deprecation of a utility) in a new major version, new features are added in
> > minor versions, and security fixes are introduced in a new patch version.
> > >> (..)
> > >
> > > +1 for simpler numbering like standard major.minor.patch:
> > > 16.0-RELEASE -> 16.0.0.
> > > 16.0-RELEASE-p1 -> 16.0.1.
> > > 16.1-RELEASE -> 16.1.0.
> > > 16.1-RELEASE-p1 -> 16.1.1.
> > >
> > > X.Y.Z numbering would imply release, maybe 16.0.0-RELEASE for clarity.
> > >
> > > 15-STABLE and 17-CURRENT could be left untouched or something like
> > > 17.0.20260225-CURRENT to mark snapshot?
> > >
> > > :-)
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> 
> 
> --
> Tomoaki AOKI    <[email protected]>
> 
>