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

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.

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.  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.

¹ 4.6.1 was tagged, but not officially released.

DES
-- 
Dag-Erling Smørgrav - [email protected]