On 5/25/26 18:14, Tuomo Latto wrote:
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.
Thank you for the thoughtful suggestion.
I agree that "(latest)" is more self-explanatory than "HEAD" and I am
happy to adopt that.
However, I would like to keep the scope simple. Managing multiple
concurrent branches is something only experienced users would do, and
they are capable of managing their own BE names. Introducing logic to
handle multiple "(latest)" tags across branches would add complexity and
potential bugs to freebsd-update.
My proposal is therefore limited to the simple case: freebsd-update
marks only the BE it last updated as "(latest)". Nothing more.
I also like "initial install" as a tag for the first BE. It is
immediately understandable without any explanation.
Takashi
