اگر پخش زنده آکادمی ۲۰۲۵ و همینطور تصاویری که از کی‌دی‌ای لینوکس منتشر شده رو دیده باشید و درمورد موز 🍌 براتون سوال شده که چی هستش، داستانش از این قراره، طبق ویکی کی‌دی‌ای:

نصف کردن یک 🍌. یا در مورد ما: ایجاد تغییرات عظیم در پیکربندی‌های sysupdate.d به گونه‌ای که نیازمند یک نسخه شکست سخت باشد که باید قبل از انتقال به نسخه جدیدتر اعمال شود.
همچنین می‌تواند برای خلاص شدن از آشغال‌های سازگاری استفاده شود. با مجبور کردن کاربران به عبور از یک نسخه خاص، می‌دانیم همه به‌روزرسانی‌های آن نسخه اعمال شده و در نتیجه می‌توانیم منطق سازگاری را حذف کنیم.

کمی تاریخچه: در ابتدا از https://files.kde.org/kde-linux/ به عنوان محل به‌روزرسانی استفاده می‌کردیم. این به طرز بدی شکاف تغییر نام به kde-linux را پر کرد و در نهایت برای مهاجرت rootfsv2 از هم پاشید. حالا به جای آن این کار را می‌کنیم:
‏* https://files.kde.org/kde-linux/ حاوی تصویر دیسک .raw و همچنین .torrent مربوط به آن است
‏* https://files.kde.org/kde-linux/sysupdate/*/ حاوی همه مصنوعات sysupdate است
‏* https://files.kde.org/kde-linux/sysupdate/v2/ و غیره نسخه‌های مختلف هستند
‏* https://files.kde.org/kde-linux/vacuum.yaml کدگذاری می‌کند که کدام بیلدها را باید برای همیشه نگه داشت (آنها را سنگ قبر می‌نامند). همچنین تصاویر طلایی را کدگذاری می‌کند (یعنی آنهایی که می‌خواهیم نگه داریم چون می‌دانیم خوب هستند)

درست. پس. چگونه سنگ قبر بسازیم؟ ابتدا با دقت زیاد درباره این مسئله فکر کنید چون تا حدودی مهم است که دقیقاً بفهمید چه کاری می‌خواهید انجام دهید...

بیایید مثال از v2 به v3 را در نظر بگیریم: می‌خواهیم نسخه‌ای در v2 ایجاد کنیم که آخرین نسخه باشد تا بتوان گفت. وظیفه این نسخه این است که یک نسخه v2 باشد در حالی که تغییرات sysupdate.d برای v3 را فراهم کند. شاید آن جمله را تا زمانی که جا بیفتد بخوانید. مصنوعات سنگ قبر باید شبیه آنهای v2 باشند، اما دستورالعمل‌های به‌روزرسانی (یعنی فایل‌های sysupdate.d) درون سنگ قبر باید شبیه آنهای v3 باشند.

در اینجا یک فهرست مفید برای این مثال آورده شده:
ممکن است عاقلانه باشد که سیستمی اختراع کنید که همه انتشارات را به پوشه ریشه جداگانه‌ای منحرف کند تا زمانی که کاملاً مطمئن شوید مهاجرت آماده است. اگر سنگ قبر بدی منتشر کنید، رفع مشکلات بسیار سخت خواهد بود.** در حال حاضر وجود ندارد اما از نظر فنی به سادگی آپلود به سرور متفاوت یا زیر مکان ریشه متفاوت است.

* اطمینان حاصل کنید v2 (یعنی git master) واقعاً کار می‌کند
‏* v3 را آماده کنید (احتمالاً در یک شاخه) و شاید کمی آن را آزمایش کنید تا مطمئن شوید پیکربندی‌های ارتقا کار می‌کنند
* نسبت به دسترسی کلید امضا فوق‌العاده مراقب باشید. شاخه‌های تصادفی به طور پیش‌فرض امضا ندارند!
* upload.sh را در شاخه v3 به‌روزرسانی کنید تا خط به‌روزرسانی v3 را شروع کند
* تعدادی بیلد v3 برای آزمایش بسازید
* یک بیلد v2 با پیکربندی‌های sysupdate.d نسخه v3 بسازید
* یک بیلد v3 بسازید تا نسخه بالاتری داشته باشید
* ارتقا را آزمایش کنید
‏* vacuum.yaml را ویرایش کنید یا از مدیر سیستم بخواهید تا بیلد v2 (و احتمالاً اولین v3 خوب) را به عنوان سنگ قبر (و احتمالاً طلایی) علامت‌گذاری کند.

https://community.kde.org/KDE_Linux/Banana_Split

@kde_fa