Should there be a What's New or changelog on the website?

vimanuelt

Should there be a prominently placed "What's New" or changelog section to keep users informed about recent updates and releases?

Robin

There's a link to News that should suffice for that, like it does on sites for most Linux distributions. But it does sound like a good idea to point people to it with a more prominent link.

vimanuelt

In UI/UX design, this distinction matters:

Use “News” when conveying time-sensitive, potentially impactful information.
Use “What’s New” to promote recent additions or encourage user engagement.

"What’s New" feels lighter, more exploratory, and often implies additions or improvements, like new features, or content. It engages curiosity rather than concern, often in a positive or promotional tone.

grahamperrin

The message of the day (MOTD) does include a link for release notes and for errata, however the linked page is non-existent.

The new link – for GhostBSD Development – is:

https://github.com/orgs/ghostbsd/projects/4

In context:

ghostbsd/ghostbsd-srcblob/e71b54acf4e343967e4558232e49890d726e9c91/usr.bin/login/motd.template#L7C25-L7C68

From https://forums.ghostbsd.org/d/344/2 (I can't edit, or delete, what's there):

Any number of useful things can be done with https://github.com/orgs/ghostbsd/projects/4/, for the development management project, in ways that can clarify things for end users (in addition to developers).

https://github.com/orgs/ghostbsd/projects/4/views/19?filterQuery=&sliceBy%5BcolumnId%5D=58331422&layout=table&visibleFields=%5B%22Title%22%2C%22Status%22%2C%22Labels%22%2C107091%2C4472642%2C58331422%5D was the result of toying for five minutes … just scratching the surface.

vimanuelt

Yes, this is a forum; but ideally, content should be automatically pruned after 90 days. Doing so would improve the forum’s freshness and reduce the accumulation of stale or outdated information. Relevant and current solutions could then be preserved and maintained in the official documentation on the ReadTheDocs site, where they can be kept accurate and searchable. Any actionable items that emerge from discussions could be tracked properly through corresponding GitHub issues, ensuring accountability and continuity.

brianthehughes

While What’s New information is shared when the ISO changes… we are neither mirroring or referencing upstream What’s New as it’s passed to the user base as packages via system updates.

I personally feel a user should be forced to scroll and accept a summary of Why/What changes they are implementing to their system every time changes are made available.

grahamperrin

brianthehughes … scroll and accept a summary of Why/What changes they are implementing to their system every time changes are made available.

A nice idea, however for ports collections I should not expect a human to write a summary.

Ports

Essential reading before allowing any upgrade to a port, regardless of whether the port is packaged:

freebsd/freebsd-portsblob/main/UPDATING for users of FreeBSD
ghostbsd/ghostbsd-portsblob/main/UPDATING for users of GhostBSD

– this type of UPDATING file is necessarily technical. We can't really change that.

Too few users realise the importance of the file. The lack of awareness can be changed.

Base OS

As far as I know, there's no Project-provided combined view of these two pages:

Unofficially:

https://bokut.in/freebsd-patch-level-table/
https://bokut.in/freebsd-patch-level-table/#releng/14.2 for releng/14.2, currently 14.2-RELEASE-p3.

Looking ahead

https://www.freebsd.org/releases/14.3R/ will gain draft release notes.

Pre-release drafts such as https://www.freebsd.org/releases/14.3R/hardware/ and https://www.freebsd.org/releases/14.3R/relnotes/ are:

hidden, but not secret
not explicitly marked as draft.

vimanuelt

grahamperrin
I am all in for automation. :-)

brianthehughes

grahamperrin
Yes, it is a lot to follow. Especially ports. Which invariably leads to the fork/original developments there of whatever it is. 🙂 I don't believe GhostBSD needs to additionally discuss the overhead of managing ports for the user base, or at least reporting the wins/challenges/blockers of building ports belongs in a the System Updates.

It would be reasonable for Software/Ports Station tool to provide add a recurring git (or gits) /usr/ghostbsd-ports, /usr/{repo}

I wasn't really including ports because packages is probably the best general user perspective to have with system and software updates.

Ports Station could be a very small tool that provides means to enable/disable, set check interval (days) for;

System

ports Y/n, Last Sync, (update)

User

TitleOfRepo /usr/projects/TitleOfRepo (edit)
(add)

I'm now wildly off topic. For me, ports aren't part of an Update Station action until long after they've struggled through build(s) to a shared win.

grahamperrin

vimanuelt

For clarity: I should not expect a human, or non-human, to write a meaningful end user-friendly summary whenever https://pkg.ghostbsd.org/stable/FreeBSD:14:amd64/latest/ changes.

Consider the commit log messages at https://freshbsd.org/ghostbsd/ports.

vimanuelt

grahamperrin
Do you have improvement ideas, and would you like to volunteer to implement them? :-) Eric could use the help.

vimanuelt

Actually, that is not just for Graham. Does anyone have improvement ideas they like to share, and would you like to volunteer to implement them? :-) Eric could use the help. Often Graham and I are most vocal and passionate, but everyone is invited to express their opinion and interest for participation. :-)

brianthehughes

It can definitely be automated…

But GhostBSD system updates are manually tested and manually released. Automated or human generated anything would be better than nothing. ;-) at present, the community anecdotally shares the changes they experience after the fact.

Some criteria of the type of information and how it might be presented

CVEs should be listed explicitly
GhostBSD project items
New Applications and Major Version Changes should also be conspicuously indicated
minor updates as a grouped set of “ongoing development”

What’s missing?

GhostBSD could be just part of New/Major or Minor updates but, I feel the project should have its own Category.

vimanuelt

brianthehughes
For ongoing development, linking directly to the development board could be an option, though it might be overwhelming for some users. An automated summary page, however, would be a more approachable and user-friendly solution.

vimanuelt

In that spirit, it may be worthwhile for GhostBSD to maintain a dedicated section on its official website or documentation portal, such as https://ghostbsd.org/security, where CVEs are clearly listed. Additionally, audit results could be published alongside each GhostBSD release or update, providing users with greater transparency and confidence in the system's security posture.

vimanuelt

For New Applications and Major Version Changes, it could be created from build output from each build run. That is a nice idea.

vimanuelt

For GhostBSD project items, can you expound on what you are interested in seeing?

brianthehughes

When it comes to updates, I think the GhostBSD * Station series deserves highlight, but perhaps I'm looking for the GhostBSD seal of approval. And after some consideration I think that could be almost entirely automated.

I suppose it comes down to a Project signature/stamp on the release. Something like a build report.

GhostBSD [Web Info/Doc Link]
Current Version ->  Update Version

base v1 (size) (date)->  v2 (size) (date)
latest v1 (size) (date)-> v2 (size) (date)

Build start date: May 14, 2025
Build attempts: 3
Build date: May 19, 2025
Release date: May 21, 2025

Approved By: Ghost Project 1 - Automatic Release
Notes: Automatic Release Stable

Proceed Y/N _

or human

Approved By: Eric
Notes: Taking a couple weeks to go camping.

vimanuelt

brianthehughes
Let's create a new thread for that discussion: https://forums.ghostbsd.org/d/384-ghostbsd-station-series-and-ports

brianthehughes

Update / Software Station integrating a console (as opposed to pop-up windows) could provide optional improved verbosity AND facilitate confirmations with the user before actions (Software install and/or System updates).

Back to the core topic of this thread...

Ongoing What's New / Changelog can and should exist, preferably automated in creation and update. Also, every effort should be made to reference upstream What's New / Changelog / Resources rather than reproducing.