What’s Coming for Future Releases of GhostBSD?

ericbsd

We’re making some important changes to how GhostBSD is built and released to provide a better, more stable experience for our users.

Starting with the next release, GhostBSD will be based on FreeBSD RELEASE instead of STABLE. This will improve stability, reduce unexpected issues, and allow us to focus more on software updates and tool development.

Additionally, we are aligning GhostBSD’s release schedule with FreeBSD, meaning future GhostBSD releases will happen in the same month as FreeBSD releases.

We’ve also introduced a new versioning scheme to make it easier to track GhostBSD releases and their FreeBSD base.

For full details on these changes, check out our blog post:
🔗 What’s Coming for Future Releases of GhostBSD

Let us know what you think! Join the discussion here or in our Telegram user group.

grahamperrin

All good, thanks!

… we may also release updated ISOs when necessary, … This ensures that new installations start with the latest security and stability improvements …

A future enhancement to the installer could run a base-specific pkg upgrade routine, if the system has an Internet connection, to gain critical security patches and important bug fixes – before first boot of the installed system.

(Possibly less resource-intensive than creating and distributing an entire ISO file.)

vimanuelt

Yes, I created that in the past, and it's what I use for PolarisBSD. The downside of a network-based install is the longer installation time, which many users find frustrating. They want to get started quickly. Eric has worked extensively to speed up the installation process, making it more efficient. Meanwhile, updates can be fetched in the background while users customize their systems, providing a smoother and more convenient experience.

vimanuelt

Another way to minimize the need for updates after installation is to refresh the ISO after each GhostBSD ports update. Adding an additional version number could help indicate which ports build is included. For example, using a format like 25.01.03, where the final .03 denotes the third ports build of the year, would provide clearer versioning for users.

fr0xk

vimanuelt If there is time and infra to do so, by all means, do it. But otherwise, look for more efficient resource management

vimanuelt

@fr0xk
Yes, another option could be to include a build number, which might prove helpful. For example, we recently encountered a situation where two ISO files had the same name but were different builds, specifically Build #83 and Build #85. Adding a build number could help avoid confusion in cases like this.