اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
إصدارات وتعديلات الإصدارات المستقرة من نواة النظام
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
بدأ نموذج الإصدارات الثابتة من نواة Linux في عام 2005، عندما تم تحديد
أنّ نموذج تطوير النواة الحالي (إصدار جديد كل شهرين أو ثلاثة أشهر) كان
لا يلبي احتياجات معظم المستخدمين. أراد المستخدمون إجراء إصلاحات للأعطال خلال هذين الشهرين أو الثلاثة
أشهر، وتبيّن لتوزيعات Linux أنّه من الصعب إبقاء النوى محدّثة
بدون ملاحظات من منتدى النوى. بوجهٍ عام، كانت محاولات الحفاظ على أمان أنظمة التشغيل الأساسية الفردية وتزويدها بأحدث إصلاحات الأخطاء جهدًا كبيرًا ومربِكًا بذله الكثير من الأفراد المختلفين.
تستند إصدارات النواة الثابتة مباشرةً إلى إصدارات "لينوس توروالدز"، ويتم
إصدارها كل أسبوع تقريبًا، استنادًا إلى عوامل خارجية مختلفة (الوقت من السنة،
والتصحيحات المتاحة، وحجم عمل القائمين بالصيانة، وما إلى ذلك). يبدأ ترقيم الإصدارات الثابتة
برقم إصدار kernel، ويتمّ إضافة رقم إضافي
في نهايته. على سبيل المثال، يُصدر "لينوس" نواة الإصدار 4.4، ثم يتم إصدار نواة مستقرة استنادًا إلى هذه النواة برقم 4.4.1 و4.4.2
و4.4.3 وما إلى ذلك. يتم عادةً اختصار هذه التسلسلة بالرقم 4.4.y عند
الإشارة إلى شجرة إصدارات الإصدار الثابت من kernel. يُشرف مطوّر واحد على صيانة كل شجرة إصدارات ثابتة للنواة، وهو المسؤول عن اختيار التعديلات اللازمة للإصدار وإدارة عملية المراجعة أو الإصدار.
يتم الاحتفاظ بالنواة الثابتة طوال مدة دورة التطوير الحالية.
بعد أن يُصدر "لينوس" نواة جديدة، يتم
إيقاف شجرة إصدارات النواة الثابتة السابقة وعلى المستخدمين الانتقال إلى النواة الأحدث التي تم إصدارها.
نواة ثابتة على المدى الطويل
بعد مرور عام على عملية الإصدار الثابت الجديد هذه، تبيّن أنّ العديد من
مستخدمي Linux يريدون توفُّر نواة لفترة أطول من
بضعة أشهر فقط. وفي ردّ على ذلك، تم إنشاء إصدار kernel (النواة) الذي يتطلّب دعمًا على المدى الطويل (LTS)، وتم إصدار أول نواة LTS (2.6.16) في عام 2006. ومنذ ذلك الحين، يتم اختيار ملف تعريف برمجي جديد لنظام التشغيل لإصداره لفترة طويلة مرة واحدة في السنة، ويحافظ مجتمع نظام التشغيل على هذا الملف لمدة عامين على الأقل.
في وقت كتابة هذه المقالة، كانت نواة LTS هي الإصدارات 4.4.y و4.9.y و4.14.y
و4.19.y و5.4.y و5.10.y. يتم طرح نواة جديدة أسبوعيًا. بسبب
احتياجات بعض المستخدمين وعمليات التوزيع، يحافظ مطوّرو نواة Linux على صيانة بعض النوى القديمة الإضافية في دورة إصدار أبطأ. يمكن العثور على معلومات عن
جميع النوى الثابتة على المدى الطويل، والمسؤول عنها، ومدة صيانتها، في صفحة
kernel.org
releases.
في المتوسط، يتم قبول 6 إلى 8 تصحيحات يوميًا لإصدارات نواة LTS، في حين تحتوي إصدارات النواة العادية
الثابتة على 10 إلى 15 تصحيحًا يوميًا. يتفاوت عدد التعديلات
حسب كل إصدار استنادًا إلى الوقت الحالي لإصدار ملف التمهيد
المعني بالتطوير والمتغيرات الخارجية الأخرى. كلما كان إصدار نواة LTS أقدم، انخفض عدد التعديلات التي يمكن تطبيقها عليه لأنّ العديد من الإصلاحات الأخيرة للمشاكل لا تسري على الإصدارات القديمة من النوى. ومع ذلك، كلما كانت النواة قديمة، كان من الصعب نقل
التغييرات التي يجب تطبيقها إلى الإصدارات القديمة، وذلك بسبب التغييرات في قاعدة البيانات. وبالتالي،
على الرغم من أنّه قد يكون هناك عدد أقل من الإصلاحات الشاملة التي يتم تطبيقها، فإنّ الجهد
المبذول في الحفاظ على نواة LTS أكبر من الجهد المبذول في الحفاظ على النواة
الثابتة العادية.
قواعد تصحيحات النواة الثابتة
ظلت قواعد ما يمكن إضافته إلى إصدار ثابت من kernel متطابقة تقريبًا منذ طرحه، ويمكن تلخيصها أدناه:
يجب أن تكون صحيحة ومجربة بشكل واضح.
يجب ألا يزيد عدد الأسطر عن 100 سطر.
يجب حلّ مشكلة واحدة فقط.
يجب إصلاح مشكلة تم الإبلاغ عنها.
يمكن أن يكون معرّف جهاز جديدًا أو مشكلة في الجهاز، ولكن لا يضيف وظائف مهمة جديدة.
يجب أن يكون قد تم دمجه في شجرة Linus Torvalds.
القاعدة الأخيرة، "يجب أن يكون قد تم دمجها في شجرة Linus Torvalds"، تمنع
منتدى kernel من فقدان الإصلاحات. لا يريد المنتدى أبدًا أن يتم تضمين إصلاح في إصدار ثابت من kernel لم يتم تضمينه في شجرة Linus Torvalds، وذلك لضمان عدم حدوث أي تراجع في الأداء لدى أي مستخدم يجري ترقية. ويمنع ذلك العديد من الصعوبات التي يمكن أن تواجهها المشروعات الأخرى التي تحافظ على فرع ثابت وفرع تطوير.
تحديثات النواة
تعهدت منتدى نواة Linux لقاعدة المستخدمين بأنّه لن يؤدي أي ترقية أبدًا إلى إيقاف أي وظائف تعمل في إصدار سابق. ولا يزال هذا الوعد صادقًا حتى اليوم. تحدث حالات التراجع، ولكنّها هي الأخطاء ذات الأولوية القصوى ويتم إصلاحها بسرعة أو يتم التراجع بسرعة عن التغيير الذي أدّى إلى التراجع من شجرة نواة Linux.
ينطبق هذا الوعد على كلّ من التحديثات المتزايدة للنواة الثابتة، وكذلك التحديثات الرئيسية الأكبر حجمًا التي يتم إجراؤها كل ثلاثة أشهر. ومع ذلك، لا يمكن لمجتمع
النواة تقديم هذا الوعد إلا للرمز الذي تم دمجه في ملف شجيرة
Linux kernel. إنّ أي رمز تم دمجه في نواة جهاز غير مضمّن في kernel.org هو رمز غير معروف، ولا يمكن التخطيط للتفاعلات معه أو حتى أخذها في الاعتبار.
يمكن أن تواجه الأجهزة المستندة إلى Linux التي تحتوي على مجموعات كبيرة من الإصلاحات مشاكل كبيرة عند
التحديث إلى نواة أحدث، وذلك بسبب العدد الكبير من التغييرات بين كل
إصدار (من 10 إلى 14 ألف تغيير لكل إصدار). تشتهر مجموعات تصحيحات نظام التشغيل SoC بشكلٍ خاص
بحدوث مشاكل في التحديث إلى نواة أحدث بسبب حجمها الكبير وتعديلها العميق
لترميز النواة الخاص بالبنية، وأحيانًا النواة الأساسية. نتيجةً لذلك، بدأ معظم مورّدي شرائح المعالجة المركزية (SoC) في استخدام إصدارات LTS بشكل موحّد لأجهزةهم، ما يتيح لهذه الأجهزة تلقّي تحديثات الأخطاء والأمان مباشرةً من منتدى نواة Linux.
الأمان
عند إصدار نواة Linux، لا يعلن منتدى نواة Linux أبدًا عن
تغييرات معيّنة على أنّها إصلاحات أمنية. ويعود السبب في ذلك إلى المشكلة الأساسية المتمثّلة في الصعوبة في تحديد ما إذا كان تصحيح الخطأ هو تصحيح أمان أم لا في وقت الإنشاء. بالإضافة إلى ذلك، لا يتم تحديد العديد من إصلاحات الأخطاء على أنّها مرتبطة بالأمان إلا بعد مرور وقت طويل، لذا ينصح مجتمع نواة Linux بشدة باستخدام جميع إصلاحات الأخطاء التي يتم إصدارها.
عند الإبلاغ عن مشاكل الأمان لمجتمع نواة Linux، يتم إصلاحها
في أقرب وقت ممكن وطرحها علنًا في شجرة التطوير والإصدارات
الثابتة. كما هو موضّح أعلاه، لا يتم وصف التغييرات تقريبًا على أنّها "إصلاح أمان"، بل تبدو مثل أيّ إصلاح آخر للأخطاء في النواة. ويتم ذلك
للسماح للجهات المتأثرة بتعديل أنظمتها قبل إعلامهم
بالمشكلة.
للتعرّف على تفاصيل الإبلاغ عن أخطاء الأمان لمجتمع نواة Linux من أجل حلّها وإصلاحها في أقرب وقت ممكن، يُرجى الرجوع إلى أخطاء الأمان في دليل مستخدمي نواة Linux ومشرفيها على الرابط www.kernel.org.
بما أنّ فريق نواة Linux لا يعلن للجمهور عن أخطاء الأمان، يتم عادةً إصدار أرقام CVE
للمشاكل المتعلّقة بنواة Linux بعد أسابيع أو أشهر أو
في بعض الأحيان بعد سنوات من دمج الإصلاح في فرعَي الإصدار الثابت والإصدارقيد التطوير.
الحفاظ على أمان النظام
عند نشر جهاز يستخدم نظام التشغيل Linux، ننصحك بشدة بأن يتولى المصنّع جميع
تحديثات نواة LTS ويطرحها للمستخدمين
بعد أن يُظهر الاختبار السليم أنّ التحديث يعمل بشكل جيد. هناك عدة مزايا لهذا الإجراء:
لقد راجع مطوّرو النواة الإصدارات ككل، وليس
أجزاء فردية منها.
من الصعب تحديد الرقع التي تعالج مشاكل "الأمان"
والتي لا تعالجها. يحتوي كل إصدار تقريبًا من قناة LTS على إصلاح واحد على الأقل لإحدى مشكلات الأمان المعروفة، بالإضافة إلى العديد من المشاكل "غير المعروفة".
إذا أظهر الاختبار مشكلة، يتفاعل مجتمع مطوّري النواة
بشكل سريع لحلّ المشكلة.
تؤدي محاولات فلترة التغييرات التي تجريها فقط إلى إنشاء شجرة ملف kernel
يتعذّر دمجها بشكل صحيح مع الإصدارات المستقبلية من الإصدارات الأساسية.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Stable kernel releases and updates\n\nThe Linux kernel stable release model started in 2005, when it was determined\nthat the existing kernel development model (a new release every 2-3 months) was\nnot meeting the needs of most users. Users wanted bugfixes made during those 2-3\nmonths, and Linux distributions found it difficult to keep kernels up to date\nwithout feedback from the kernel community. In general, attempts to keep\nindividual kernels secure and with the latest bugfixes was a large and confusing\neffort by lots of different individuals.\n\n\nStable kernel releases are based directly on Linus Torvalds' releases, and are\nreleased every week or so, depending on various external factors (time of year,\navailable patches, maintainer workload, etc.). The numbering of the stable\nreleases starts with the number of the kernel release, and an additional number\nis added to the end of it. For example, the 4.4 kernel is released by Linus, and\nthen the stable kernel releases based on this kernel are numbered 4.4.1, 4.4.2,\n4.4.3, and so on. This sequence is usually shortened with the number 4.4.y when\nreferring to a stable kernel release tree. Each stable kernel release tree is\nmaintained by a single kernel developer, who is responsible for picking the\nneeded patches for the release and managing the review/release process.\n\n\nStable kernels are maintained for the length of the current development cycle.\nAfter Linus releases a new kernel, the previous stable kernel release tree is\nstopped and users must move to the newer released kernel.\n\nLong-term stable kernels\n------------------------\n\n\nAfter a year of this new stable release process, it was determined that many\ndifferent users of Linux wanted a kernel to be supported for longer than just a\nfew months. In response, the Long Term Supported (LTS) kernel release was\ncreated, with the first LTS kernel (2.6.16) released in 2006. Since then, a new\nLTS kernel has been selected once a year and kernel community maintains that\nkernel for a minimum of 2 years.\n\nAt the time of this writing, the LTS kernels are the 4.4.y, 4.9.y, 4.14.y,\n4.19.y, 5.4.y, and 5.10.y releases. A new kernel is released weekly. Due to\nthe needs of some users and distributions, a few additional older kernels are\nmaintained by kernel developers at a slower release cycle. Information about\nall long-term stable kernels, who is in charge of them, and how long they are\nmaintained, can be found on the\n[kernel.org\nreleases](https://www.kernel.org/category/releases.html) page.\n\n\nLTS kernel releases average 6-8 patches accepted per day, while the normal\nstable kernel releases contain 10-15 patches per day. The number of patches\nfluctuates per release given the current time of the corresponding development\nkernel release, and other external variables. The older a LTS kernel is, the\nless patches are applicable to it as many recent bugfixes are not relevant to\nolder kernels. However, the older a kernel is, the harder it is to backport the\nchanges that are needed to be applied, due to the changes in the codebase. So\nwhile there might be a lower number of overall patches being applied, the effort\ninvolved in maintaining a LTS kernel is greater than maintaining the normal\nstable kernel.\n\nStable kernel patch rules\n-------------------------\n\nThe rules for what can be added to a stable kernel release have remained\nalmost identical since its introduction and are summarized below:\n\n- Must be obviously correct and tested.\n- Must not be bigger than 100 lines.\n- Must fix only one thing.\n- Must fix something that has been reported to be an issue.\n- Can be a new device id or quirk for hardware, but not add major new functionality.\n- Must already be merged into Linus Torvalds' tree.\n\n| **Note:** For a full list of the rules for patches to be accepted into a stable kernel release, refer to the [Documentation/process/stable_kernel_rules.rst](https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html) kernel file.\n\nThe last rule, \"Must already be merged into Linus Torvalds' tree\", prevents\nthe kernel community from losing fixes. The community never wants a fix to go\ninto a stable kernel release that is not already in Linus Torvalds' tree, so\nthat anyone who upgrades should never see a regression. This prevents many\nproblems that other projects who maintain a stable and development branch can\nhave.\n\nKernel updates\n--------------\n\nThe Linux kernel community has promised its userbase that no upgrade\never breaks anything that is working in a previous release. That\npromise still holds true today. Regressions do happen, but those are the highest\npriority bugs and are either quickly fixed, or the change that caused the\nregression is quickly reverted from the Linux kernel tree.\n\nThis promise holds true for both the incremental stable kernel updates, as\nwell as the larger major updates that happen every three months. However, the\nkernel community can only make this promise for the code that is merged into the\nLinux kernel tree. Any code that is merged into a device's kernel that is not in\nthe [kernel.org](https://www.kernel.org/) releases is unknown and\ninteractions with it can never be planned for, or even considered.\n\nDevices based on Linux that have large patch sets can have major issues when\nupdating to newer kernels, because of the large number of changes between each\nrelease (10-14 thousand changes per release). SoC patchsets are especially known\nto have issues with updating to newer kernels due to their large size and heavy\nmodification of architecture specific, and sometimes core, kernel code. As a\nresult, most SoC vendors are starting to standardize on using the LTS releases\nfor their devices, enabling those devices to receive bug and security updates\ndirectly from the Linux kernel community.\n\nSecurity\n--------\n\nWhen doing kernel releases, the Linux kernel community almost never declares\nspecific changes as *security fixes*. This is due to the basic problem of\nthe difficulty in determining if a bugfix is a security fix or not at the time\nof creation. Also, many bugfixes are only determined to be security related\nafter much time has passed, so the kernel community strongly recommends always\ntaking all bugfixes that are released.\n| **Note:** For details on Linus Torvalds' statement on security fixes, refer to the relevant [email\n| thread](http://marc.info/?t=121507404600023&r=4&w=2).\n\n\nWhen security problems are reported to the kernel community, they are fixed as\nsoon as possible and pushed out publicly to the development tree and the\nstable releases. As described above, the changes are almost never described as\na \"security fix\", but rather look like any other bugfix for the kernel. This is\ndone to allow affected parties the ability to update their systems before the\nreporter of the problem announces it.\n\nFor details on reporting security bugs to the kernel community to get\nthem resolved and fixed as soon as possible, refer to\nSecurity bugs in *The Linux kernel user's and administrator's guide* at\n[www.kernel.org](https://www.kernel.org).\n\n\nBecause security bugs are not announced to the public by the kernel team, CVE\nnumbers for Linux kernel-related issues are usually released weeks, months, and\nsometimes years after the fix was merged into the stable and development\nbranches.\n\n### Keep a secure system\n\nWhen deploying a device that uses Linux, we strongly recommend that all\nLTS kernel updates be taken by the manufacturer and pushed out to their users\nafter proper testing shows the update works well. This has several advantages:\n\n- Releases have been reviewed by the kernel developers as a whole, not in individual parts.\n- It's difficult to determine which patches fix \"security\" issues and which do not. Almost every LTS release contains at least one known security fix, and many yet \"unknown.\"\n- If testing shows a problem, the kernel developer community reacts quickly to resolve the issue.\n- Attempts to filter out only the changes you run results in a kernel tree that is impossible to merge correctly with future upstream releases."]]