one change in #FreeBSD pkgbase compared to freebsd-update is that when a kernel module is updated, you get an entire new kernel package (FreeBSD-kernel-generic) rather than just an updated module (foo.ko).

[lw@mastodon.bsd.cafe]

one change in #FreeBSD pkgbase compared to freebsd-update is that when a kernel module is updated, you get an entire new kernel package (FreeBSD-kernel-generic) rather than just an updated module (foo.ko).

the downside is the update is larger, since the kernel package is about 45MB, but the upside is that because it updates /boot/kernel/kernel, the current patch level is always shown in uname -r after rebooting.

i think this is probably better overall, because a lot of people used to get confused about why they'd update to 15.0p3, but uname still showed 15.0p1, or whatever.

[tomaoki@mastodon.bsd.cafe]

@lw
Exactly.
The problem often fires up on forums.freebsd.org.
I thought why you hesitate with -p* approach should be because of this from start.

OTOH, why I'm sticking with keeping backward compatibility is for in-the-wild scripts / codes.
On FreeBSD src and ports, scripts and/or codes relying on current versioning scheme would be fixed to fit new versioning scheme.
So would be on large enough organizations if enough notification periods are given (1 or more major releases after the first headsup).

Personal users who is administrating the own computers like me would do, too, as the person (including myself) should know what to do.

The problem in the middle range. In small organizations that the dev who wrote the scripts / codes are already gone wouldn't be able to fix them unless someone else who can do comes into. This is why backward compatibilities are quite important.