# إصدارات يناير 2026

**URL:** <https://meta.discourse.org/t/january-2026-releases/393903>\
**Category:** Announcements\
**Tags:** release-notes\
**Created:** [28 يناير 2026، 5:35م UTC](https://meta.discourse.org/t/january-2026-releases/393903 "2026-01-28T17:35:34Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![Simon\_Manning](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon_manning/32/198596_2.png) [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)\
**Post date:** [29 يناير 2026، 10:38ص UTC](https://meta.discourse.org/t/january-2026-releases/393903/9 "2026-01-29T10:38:03Z")

</div>

سواء كان ذلك من إصدار معين إلى آخر أو من نقطة عشوائية في `latest` إلى أحدث `latest`، إذا تعذر تطبيق تغيير بين الالتزامين x و y بواسطة المحدِّث المدمج، مما يتطلب بدلاً من ذلك إعادة بناء الحاوية من صورة جديدة، فهل سيحدد نظام ملاحظات الإصدار الجديد ذلك ويدون الحاجة إلى إعادة بناء؟

* * *

بشكل منفصل، هل سيمنع المحدِّث المدمج التحديث، ويطلب إعادة بناء؟

فهمي العام للمحدِّث المدمج هو أنه بعد تحديث `Docker_manager`، سيمنع تحديث `Discourse` إذا كانت هناك حاجة لإعادة بناء. لم أر هذا موثقًا رسميًا، ومن خلال التجربة لم يبدُ موثوقًا به تمامًا.

على وجه التحديد، في بعض الأحيان يؤدي التنقل من تحديث `Docker_manager` المكتمل إلى صفحة الإصدارات إلى توفر تحديث `Discourse` للبدء، ثم فقط بعد تحديث الصفحة سيتم حظره. [سأشير إلى أن آخر مرة رأيت فيها ذلك حدث كانت منذ وقت طويل، ربما تم إصلاحه.]

---

_[View the full topic](https://meta.discourse.org/t/january-2026-releases/393903)._
