Date: Mon, 25 May 2026 12:14:21 +0300 From: Tuomo Latto <djv@iki.fi> To: freebsd-stable@FreeBSD.org Subject: Re: Proposal: Improve BE naming convention in freebsd-update install Message-ID: <35C0A0DA-DEE3-49DD-81E3-E71E56190A3A@iki.fi> In-Reply-To: <cfc338d2-16cd-4316-879d-092674d248c1@shirt.ocn.ne.jp> References: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp> <BL4PR11MB88249FD96B59C106E57DAD26E60A2@BL4PR11MB8824.namprd11.prod.outlook.com> <cfc338d2-16cd-4316-879d-092674d248c1@shirt.ocn.ne.jp>
index | next in thread | previous in thread | raw e-mail
On 25 May 2026 9.41.44 GMT+03:00, Takashi Shimizu <qqyr7xx9k@shirt.ocn.ne.jp> wrote:
>I think there was a misunderstanding about the core of my proposal. I was not suggesting a naming convention for users to follow manually. The proposal is that freebsd-update itself should automatically rename the current BE to "HEAD" after each install operation.
>
>To be more explicit:
>
> * When freebsd-update install completes, it renames the current BE to
> "HEAD" automatically.
> * The next time freebsd-update install runs, it again renames the
> current BE to "HEAD", overwriting the previous name.
> * This guarantees that "HEAD" always refers to the latest state
> managed by freebsd-update, without any user intervention.
>
>This addresses your concern about name shifting. The shifting is done by freebsd-update itself, not by the user.
>
>Regarding your point that "HEAD" does not describe what is in the BE: that is intentional. The pre-update snapshot retains the version-stamped name such as 15.0-RELEASE-p8_2026-05-24, which does describe its contents. "HEAD" is not meant to describe contents but to indicate position: it is always the tip of the freebsd-update managed state, analogous to HEAD in version control.
>
>I agree that "original" has the same weakness in not describing its contents. Naming it after the installed version, such as "15.0-RELEASE", would be more informative.
As someone who does not use BEs and doesn't know very much about them,
I have some thoughts. So, take them for what they're worth.
HEAD is not a good name because you have to explain it. It also has traditionally
referred to sources and I don't think introducing it somewhere else is a good idea,
because that usage is distinct enough to cause confusion, especially since the other
suggested names refer to source versions.
If the idea is that it is the latest update and that we generally boot that latest version
except in some specific circumstances, the word "default" does rather come to mind.
Of course, that word by itself is not very descriptive beyond that.
Therefore, it would make sense to use "<Freebsd version description> (default)" instead,
where the version would be as you describe. You could even suggest version naming
conventions for manual usage such as "15-STABLE_<source timestamp>" or something.
Using " (default)" would mean you'd have to update the names so that it only exists
in one of them, which isn't that different from "HEAD". Although, if there actually is
a separate mechanism for a boot default, even if it's just picking the one that was used
the last time, that word simply won't do as you could have a different boot default
from the one named "default" and always moving that tag around would defeat the purpose
of having it.
Instead, you could do " (latest)" but, if you run forks or several branches, that word
could either be confusing OR a very good choice, because then each branch could have
that tag to represent their "head". In that case, you'd only remove it from the name,
if the version you were updating from had that tag and you were using the same
version/branch name, so to speak. You'd (almost) always add it.
The first install being simply called "original" is almost as bad as calling the "HEAD"
simply "default". It would make more sense to have the version description there too.
I could see other words being used as tags there too, such as "initial" and "first", perhaps
maybe "original install", "initial install", and so on. The exact choice doesn't matter as
long as it is something you don't have think about at all in order to understand, which
is why that second word might be a useful addition.
So, I might be misunderstanding something here but maybe you could have
a pathological, likely non-realistic, example like the following, sorted by newest to oldest,
which may not be the best choice here, where someone would have started from
a release install, tracked 14-stable, went with 14.0 patchlevels for a while, upgraded to 14.1,
then went back to tracking 14-stable, and then upgrading to 15.0 release and also tracking
16-CURRENT simultaneously.
They'd have several concurrent versions installed, which may or may not make sense.
It would be messy to do this, I guess, but, importantly, the list is still somewhat legible
and there's some sense of what is what and the "head" of each branch is marked:
"16-CURRENT_<ts3> (latest)"
"16-CURRENT_<ts2>"
"15.0-RELEASE-p8 (latest)"
"15.0-RELEASE-p7"
"16-CURRENT_<ts1>"
"15.0-RELEASE-p6"
"14-STABLE_<ts9> (latest)"
"14-STABLE_<ts8>"
"14-STABLE_<ts7>"
"14-STABLE_<ts6> xxbug test patch 2"
"14-STABLE_<ts5> xxbug test patch 1"
"14-STABLE_<ts4>"
"14-STABLE_<ts3>"
"14.1-RELEASE-p1 (latest)"
"14.1-RELEASE"
"14.0-RELEASE-p6 (latest)"
"14-STABLE_<ts2>"
"14-STABLE_<ts1>"
"14.0-RELEASE (initial install)"
You might not want to do this naming by hand but, if all the tools (overridably)
standardised the format, you could also create the facility (switches, UI fields)
to easily add some descriptions ("xxbug [...]") in names for e.g. testing purposes.
So, for what it's worth.
--
Tuomo
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35C0A0DA-DEE3-49DD-81E3-E71E56190A3A>