On 25 May 2026 9.41.44 GMT+03:00, Takashi Shimizu <[email protected]>
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
