From nobody Mon May 25 09:14:21 2026 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gP9Dy4B1qz6f0vK for ; Mon, 25 May 2026 09:14:26 +0000 (UTC) (envelope-from djv@iki.fi) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gP9Dx5WTsz411Q for ; Mon, 25 May 2026 09:14:25 +0000 (UTC) (envelope-from djv@iki.fi) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iki.fi header.s=meesny header.b=RVURgrtU; dmarc=none; spf=pass (mx1.freebsd.org: domain of djv@iki.fi designates 195.140.195.201 as permitted sender) smtp.mailfrom=djv@iki.fi; arc=pass ("iki.fi:s=meesny:i=1") Received: from ehlo.thunderbird.net (2001-14ba-a0a4-9c00-a2cb-fdff-fe5b-fa50.rev.dnainternet.fi [IPv6:2001:14ba:a0a4:9c00:a2cb:fdff:fe5b:fa50]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) (Authenticated sender: djv) by meesny.iki.fi (Postfix) with ESMTPSA id 4gP9Dt5lL2zyYG for ; Mon, 25 May 2026 12:14:22 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1779700462; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vtnaRHjyem3xUXTqmKnczyx2cOMfijMi22svcmkuz70=; b=RVURgrtUIAjVW1+fvsugHqxCrH2NfgUuvBxtItp8iFYhC/CdsPJKFQKrca6h56g6+gbhBu qoXkfylZURVvQHzu0PlxPDdnPAUNAROl2Vbqc+A9AvIz1+vM/6j5MFts6fakxHkKjIIMcq gtT7PR4OfYfVkTEXuQflBW1QqL6kpZY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1779700462; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vtnaRHjyem3xUXTqmKnczyx2cOMfijMi22svcmkuz70=; b=iI5Mnd7N9dqgeb2EnMZD6RJ1lqbkz0M4prpSAMNy0pNESqJDSWWzwNyNVluIuTZyAvRn9f Ig0itp+UwnsMMOPalm0rPZZDoRwViVB+fQ6D9odbM9Yy/dIe2EH7/g15BVHWWfhMtoqUah KkVmDjj2fDdApMtmRliMvNB0I+/uvTs= ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=meesny; cv=none; t=1779700462; b=nQo8ro4vJVvE4BCvjqds68CJcg2tBYMSACFjcPDf9jCc6beNizwByc4AmxHeC3F1/sA6zF Dtm8vy11ItMHHaYZftIK9J3ntgOhNM987cmfVQy6jDsP19fKMbO1Dz+6uFCGHOVB2NVQFM sX18qNTqZaHuaBnWLuGqvvL5K4l2uK0= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=djv smtp.mailfrom=djv@iki.fi Date: Mon, 25 May 2026 12:14:21 +0300 From: Tuomo Latto To: freebsd-stable@FreeBSD.org Subject: Re: Proposal: Improve BE naming convention in freebsd-update install User-Agent: K-9 Mail for Android In-Reply-To: References: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp> Message-ID: <35C0A0DA-DEE3-49DD-81E3-E71E56190A3A@iki.fi> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.32 / 15.00]; ARC_ALLOW(-1.00)[iki.fi:s=meesny:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.923]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[iki.fi:s=meesny]; R_SPF_ALLOW(-0.20)[+a:smtp.iki.fi]; RCVD_IN_DNSWL_LOW(-0.10)[195.140.195.201:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:29432, ipnet:195.140.194.0/23, country:FI]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[iki.fi:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[iki.fi]; MLMMJ_DEST(0.00)[freebsd-stable@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[iki.fi:+] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4gP9Dx5WTsz411Q On 25 May 2026 9=2E41=2E44 GMT+03:00, Takashi Shimizu wrote: >I think there was a misunderstanding about the core of my proposal=2E I w= as not suggesting a naming convention for users to follow manually=2E The p= roposal is that freebsd-update itself should automatically rename the curre= nt BE to "HEAD" after each install operation=2E > >To be more explicit: > > * When freebsd-update install completes, it renames the current BE to > "HEAD" automatically=2E > * The next time freebsd-update install runs, it again renames the > current BE to "HEAD", overwriting the previous name=2E > * This guarantees that "HEAD" always refers to the latest state > managed by freebsd-update, without any user intervention=2E > >This addresses your concern about name shifting=2E The shifting is done b= y freebsd-update itself, not by the user=2E > >Regarding your point that "HEAD" does not describe what is in the BE: tha= t is intentional=2E The pre-update snapshot retains the version-stamped nam= e such as 15=2E0-RELEASE-p8_2026-05-24, which does describe its contents=2E= "HEAD" is not meant to describe contents but to indicate position: it is a= lways the tip of the freebsd-update managed state, analogous to HEAD in ver= sion control=2E > >I agree that "original" has the same weakness in not describing its conte= nts=2E Naming it after the installed version, such as "15=2E0-RELEASE", wou= ld be more informative=2E As someone who does not use BEs and doesn't know very much about them, I have some thoughts=2E So, take them for what they're worth=2E HEAD is not a good name because you have to explain it=2E It also has trad= itionally referred to sources and I don't think introducing it somewhere else is a g= ood idea, because that usage is distinct enough to cause confusion, especially since= the other suggested names refer to source versions=2E If the idea is that it is the latest update and that we generally boot tha= t latest version except in some specific circumstances, the word "default" does rather come= to mind=2E Of course, that word by itself is not very descriptive beyond that=2E Therefore, it would make sense to use " (defa= ult)" instead, where the version would be as you describe=2E You could even suggest versi= on naming conventions for manual usage such as "15-STABLE_" or som= ething=2E Using " (default)" would mean you'd have to update the names so that it on= ly exists in one of them, which isn't that different from "HEAD"=2E Although, if the= re 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 boo= t default from the one named "default" and always moving that tag around would defea= t the purpose of having it=2E Instead, you could do " (latest)" but, if you run forks or several branche= s, that word could either be confusing OR a very good choice, because then each branch = could have that tag to represent their "head"=2E In that case, you'd only remove it f= rom the name, if the version you were updating from had that tag and you were using the = same version/branch name, so to speak=2E You'd (almost) always add it=2E The first install being simply called "original" is almost as bad as calli= ng the "HEAD" simply "default"=2E It would make more sense to have the version descripti= on there too=2E I could see other words being used as tags there too, such as "initial" an= d "first", perhaps maybe "original install", "initial install", and so on=2E The exact choice= doesn't matter as long as it is something you don't have think about at all in order to unde= rstand, which is why that second word might be a useful addition=2E So, I might be misunderstanding something here but maybe you could have a pathological, likely non-realistic, example like the following, sorted b= y newest to oldest, which may not be the best choice here, where someone would have started fr= om a release install, tracked 14-stable, went with 14=2E0 patchlevels for a w= hile, upgraded to 14=2E1, then went back to tracking 14-stable, and then upgrading to 15=2E0 release= and also tracking 16-CURRENT simultaneously=2E They'd have several concurrent versions installed, which may or may not ma= ke sense=2E 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 ma= rked: "16-CURRENT_ (latest)" "16-CURRENT_" "15=2E0-RELEASE-p8 (latest)" "15=2E0-RELEASE-p7" "16-CURRENT_" "15=2E0-RELEASE-p6" "14-STABLE_ (latest)" "14-STABLE_" "14-STABLE_" "14-STABLE_ xxbug test patch 2" "14-STABLE_ xxbug test patch 1" "14-STABLE_" "14-STABLE_" "14=2E1-RELEASE-p1 (latest)" "14=2E1-RELEASE" "14=2E0-RELEASE-p6 (latest)" "14-STABLE_" "14-STABLE_" "14=2E0-RELEASE (initial install)" You might not want to do this naming by hand but, if all the tools (overri= dably) standardised the format, you could also create the facility (switches, UI = fields) to easily add some descriptions ("xxbug [=2E=2E=2E]") in names for e=2Eg= =2E testing purposes=2E So, for what it's worth=2E --=20 Tuomo