From nobody Wed Sep 11 12:13:13 2024 X-Original-To: freebsd-users-jp@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 4X3fc01jvHz5WY2G for ; Wed, 11 Sep 2024 12:13:20 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4X3fbz4hPsz4gwC for ; Wed, 11 Sep 2024 12:13:19 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 48BCDE4X035890; Wed, 11 Sep 2024 21:13:15 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1726056795; bh=FP6/4+zxneWmso9aYzkrUHEmtzcwet34Xf65ZINruNk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Df0j8aToBMcSK/uTegWyn9rhpsol2+XMusUTr1pCQVUbaL+ELCnCh5BwjgSiYiAib CVkEn9yAl34HgPu32nTdww4rfvd7zW0bxZpVYFsxydyXAWawOvA85MYRWvmOgshk3+ /kW0BzOU50kDSOWZvmofZQ6Zf5LsZRtxqDcGTEZA= Date: Wed, 11 Sep 2024 21:13:13 +0900 From: Tomoaki AOKI To: zen-freebsd-ml@suzuki.que.ne.jp Cc: freebsd-users-jp@freebsd.org Subject: Re: =?UTF-8?B?RnJlZUJTROOBruODquODquODvOOCueOCteOCpOOCr+ODqw==?= =?UTF-8?B?5aSJ5pu044Gr44Gk44GE44Gm?= Message-Id: <20240911211313.1852f233d7a4bb3a5000335f@dec.sakura.ne.jp> In-Reply-To: <20240911.161356.1304132417828656068.inetd@x.inetd.co.jp> References: <20240911.161356.1304132417828656068.inetd@x.inetd.co.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Discussion relevant to FreeBSD communities in Japan List-Archive: https://lists.freebsd.org/archives/freebsd-users-jp List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-users-jp@freebsd.org Sender: owner-freebsd-users-jp@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4X3fbz4hPsz4gwC On Wed, 11 Sep 2024 16:13:56 +0900 (JST) zen-freebsd-ml@suzuki.que.ne.jp wrote: > 鈴木＠葛飾区です。 > > 久々のMLへの投稿です。。 > > 間抜けなことにFreeBSDのリリースサイクルが変更されたことに昨日気づきま > した (;_;) > > 13.4とか言っているので13.3からまだ半年なのに変則的なリリースだなぁ？と > 思っていろいろ検索していたら7月に今後のマイナーバージョンのリリースは > 半年ごとになりますみたいな決定がされていたようです。 > > https://lists.freebsd.org/archives/freebsd-announce/2024-July/000143.html > > www.freebsd.orgのニュースリリースにも特に掲載はなく、まったく気づきま > せんでした。 > > たとえば今後の13と14のリリース予定はこんな感じらしいです。 > > 13と14抜粋 > 13.3: Mar 2024 Dec 2024 > 13.4: Sep 2024 Jun 2025 > 13.5: Mar 2025 Apr 2026* > > 14.1: Jun 2024 Mar 2025 > 14.2: Dec 2024 Sep 2025 > 14.3: Jun 2025 Jun 2026 > 14.4: Mar 2026 Dec 2026 > 14.5: Sep 2026 Jun 2027 > 14.6: Mar 2027 Nov 2028* > > 現状FreeBSD13.3のサーバーがそれなりにあるため1台づつfreebsd-updateでの > 更新は現実的ではないため1台で更新して更新後のバイナリを各マシンに配布、 > 設定ファイル等は変更の必要なもののみ配布することでバージョンアップを簡 > 略化していましたが更新の際にはそれなりに確認等も必要で楽では無い。。 > > そこに来て半年に1回のマイナーバージョンアップという話を知ってすっかり > 心が折れました。。。 > > Red Hatもマイナーバージョンアップはありますが、多くの場合いつもよりアッ > プデートに時間がかかるな、くらいで設定ファイルもそこまで変更はなかった > です(これまで)。 > > 自分的には最早これまでか、、という感じです。 > (2026年の13.5のEOLまでに脱出計画かなぁ。。) > > みなさんはどうされていますか？？ > --- > すずき 私の場合、FreeBSDで使っているPCがノート1台だけということもありますが、 日常使用は最新のstableブランチ（現在はstable/14）を原則1回/週でソース から更新（セキュリティ関係や注目すべき更新があった場合は臨時更新も）、 1回/2週間～1ヶ月で別物理ドライブのmainブランチをソースから更新という 運用です。 ※つまり、まだ先ですが今後stable/15ブランチが切られたら日常使用の 　環境はそちらに切り替えです。 mainブランチは非常時のレスキュー用 兼 MFCされたときの影響が大きそうな 更新のテスト環境です。　ここで問題になりそうであれば何らかの方法で （Bugzillaへの不具合情報登録・freebsd-current MLでの注意喚起・ dev-commits-src-main MLの当該コミット分への返信等）フィードバックして 修正又はMFC予定の撤回を求めることにしています。 そういった形で主にstableブランチを使用していますが、 　・portsからインストールしたカーネルモジュールはbaseの更新毎に 　　必ずportsからビルド・インストールしなおす。 　・ZFSを使用し、最悪の場合戻せるようにスナップショットを取っておく。 　・確実に何も使っていないことを確認するまで`make delete-old-libs`は 　　絶対に行わない。 　・mainブランチで問題が出ていないことが確認できていてブランチを 　　切り替えるとき以外はZFSのプールのupgradeは絶対に行わず、 　　行う場合は先にブートコードを更新する。 という運用で、次のstableブランチへの切り替え以外かつビルド・インストール でエラーにならなかった場合は困ったことはありません。 ※portsの更新関係での困りごとのほうが遥かに多いです。 英語ではありますがfreebsd-stable MLを見ていると、同じブランチ （relengは対応するstableブランチ単位で判断）内で互換性問題が 生じたらたいてい誰かが騒ぎ出しますので、releng（14系での次は releng/14.2）ブランチが切られる前にある程度対処方法も掴めるかと 思います。 13系なら13系、14系なら14系の中であればいいのですが、このレベルを 乗り換える際はmainブランチの更新頻度を引き上げて安全性を確認する 等の対応はしています。　リスクが段違いになりますので。 -- 青木 知明 [Tomoaki AOKI]