This might need some hand-wavy dates in the final release notes blurb as @phk noted in the thread on arch@.

This also doesn't currently say anything about ports. I'm not sure if we will want something explicit about the fact that if 32-bit platforms are removed in 15.0 that means no pre-built packages, and that ports will remove support for those platforms once stable/14 goes EOL or if the fact that all falls out implicitly is sufficient?

ports will remove support for those platforms once stable/14 goes EOL or if the fact that all falls out implicitly is sufficient

Much better to be explicit here

32-bit kernels and worlds are now deprecated and may be

Can I understand this as 32 bit jails on 64 bit hosts no longer being a supported use case?

In D41164#937343, @fuz wrote:

32-bit kernels and worlds are now deprecated and may be

Can I understand this as 32 bit jails on 64 bit hosts no longer being a supported use case?

That will be supported. If the text suggests otherwise we should fix the language

That will be supported. If the text suggests otherwise we should fix the language

Yes, I believe the current text suggests that.

If 32 bit jails on 64 bit hosts will remain a supported use case, then 32-bit worlds are not deprecated

That doesn't necessarily follow -- we could support 32-bit binaries/jails on 64-bit hosts for backwards compatibility - for instance, running a FreeBSD 14.0 32-bit world on a FreeBSD 15.0 64-bit kernel, but not building FreeBSD 15.0 32-bit worlds.

In D41164#937367, @emaste wrote:

If 32 bit jails on 64 bit hosts will remain a supported use case, then 32-bit worlds are not deprecated

That doesn't necessarily follow -- we could support 32-bit binaries/jails on 64-bit hosts for backwards compatibility - for instance, running a FreeBSD 14.0 32-bit world on a FreeBSD 15.0 64-bit kernel, but not building FreeBSD 15.0 32-bit worlds.

I apologise for my question being vague. I specifically wanted to know if coming forwards, building 32 bit worlds for use in jails (or as a pseudo 32-bit install) will stay supported. Seems like the consensus is "no it won't".

So which is it ?

A) We support 32 bit jails and do not deprecate 32 bit worlds ?

B) We deprecate 32 bit world AND 32 bit jails ?

Also:

If we support 32 bit jails: How long do we commit to supporting the 32bit 14.X kernel ABI ?

In D41164#937728, @phk wrote:

So which is it ?

A) We support 32 bit jails and do not deprecate 32 bit worlds ?

B) We deprecate 32 bit world AND 32 bit jails ?

Hmm, perhaps it would help to clarify, we would support _running_ a 32-bit jail. We wouldn't support _building_ a tarball of 15.x binaries that could be used to deploy a jail. I guess I generally think of jails only as the former (you can extract an i386 tarball into a chroot and run it), not the latter. I think this means B) above, but I'm not sure if we are interpreting words the same. I thought this paragraph was clear about executing (rather than building) 32-bit binaries and that it says explicitly your need an older userland base system to keep using an i386 jail:

	Support for executing 32-bit binaries on 64-bit platforms via
	COMPAT_FREEBSD32 will remain supported for the foreseeable
	future.  This includes support for 32-bit jails.  However,
	since future releases will not provide worlds or release
	images, 32-bit jails would need to be built from an earlier
	release (e.g. 14.0).

Also:

If we support 32 bit jails: How long do we commit to supporting the 32bit 14.X kernel ABI ?

We have yet to remove the 3.x kernel ABI support from the source (it is possible to still run an old 1.x a.out binary under COMPAT_FREEBSD32 today if you have it lying around and I think @kib has even done it somewhat recently), and GENERIC on x86 still has COMPAT_FREEBSD4. But again, this is about how long we support running an existing 32-bit binary, not about how long we support building an entire 32-bit userland base system. That's not a very satisfying answer though. We could perhaps put a stake in the ground about how old of compat we are willing to ship in GENERIC at least. (For example, should we drop some COMPAT_FREEBSD<n> from GENERIC in 14.0? If so, then that policy will carry over to 32-bit support since the timeline at which COMPAT_FREEBSD14 gets taken out of GENERIC is effectively the timeline for COMPAT_FREEBSD32.) I guess for now though we have no timeline or expectation for removing COMPAT_FREEBSD32 or older COMPAT_FREEBSD<n>.

So one could use poudriere to build a 14 i386 jail, but not a 15?

And at what point do we tear it down. Just after 14cor just before 15? For armv7 I thought the latter...

So if I understand your position, what we are trying to say is:

From FreeBSD 15 there will no longer be any 32 bit versions of FreeBSD.

However, a FreeBSD-15 64bit system will still be able to run older 32bit and 64bit FreeBSD releases inside a jail.

I strongly suggest replacing "older" with "less than 10 years old", for some value of 10, as a matter of principle.

In D41164#937876, @phk wrote:

So if I understand your position, what we are trying to say is:

From FreeBSD 15 there will no longer be any 32 bit versions of FreeBSD.

However, a FreeBSD-15 64bit system will still be able to run older 32bit and 64bit FreeBSD releases inside a jail.

I strongly suggest replacing "older" with "less than 10 years old", for some value of 10, as a matter of principle.

Yes.

@jhb

IMO the current text does a really bad job at communicating that.

Can I suggest we add a "Tl;dr" summary along the two lines I wrote at the top ?

I've removed all mentions of jails since that is seemingly too confusing.

My main suggestion is that we include some note that this is subject to change (either intended to remain in the release notes, or just an internal note that we will remove before publishing the release notes). I'd like to avoid news sites from picking up these notes and publishing them as fact if we are not yet fully committed to that decision.

In D41164#944066, @emaste wrote:

My main suggestion is that we include some note that this is subject to change (either intended to remain in the release notes, or just an internal note that we will remove before publishing the release notes). I'd like to avoid news sites from picking up these notes and publishing them as fact if we are not yet fully committed to that decision.

The commit log says that. Perhaps I can add a paragraph to the end that copies some of what is in the commit log. The commit log for the warning message also has a similar caveat.