از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
مدل انتشار پایدار هسته لینوکس در سال 2005 شروع شد، زمانی که مشخص شد مدل توسعه هسته موجود (یک نسخه جدید هر 2-3 ماه) نیازهای اکثر کاربران را برآورده نمی کند. کاربران خواهان رفع اشکالاتی بودند که در طی آن 2 تا 3 ماه ایجاد شده بودند، و توزیعهای لینوکس بهروز نگه داشتن هستهها بدون بازخورد از جامعه هسته دشوار بود. به طور کلی، تلاش برای ایمن نگه داشتن کرنل های فردی و با آخرین رفع اشکال، تلاش بزرگ و گیج کننده بسیاری از افراد مختلف بود.
نسخههای هسته پایدار مستقیماً بر اساس نسخههای لینوس توروالدز هستند و بسته به عوامل خارجی مختلف (زمان سال، وصلههای موجود، حجم کاری نگهدارنده و غیره) هر هفته یا بیشتر منتشر میشوند. شماره گذاری نسخه های پایدار با شماره انتشار هسته شروع می شود و یک عدد اضافی به انتهای آن اضافه می شود. به عنوان مثال، هسته 4.4 توسط لینوس منتشر می شود و سپس انتشارات هسته پایدار مبتنی بر این هسته به شماره های 4.4.1، 4.4.2، 4.4.3 و ... می باشد. این دنباله معمولاً با عدد 4.4.y کوتاه می شود که به درخت انتشار هسته پایدار اشاره می شود. هر درخت انتشار هسته پایدار توسط یک توسعهدهنده هسته نگهداری میشود که مسئول انتخاب وصلههای مورد نیاز برای انتشار و مدیریت فرآیند بررسی/انتشار است.
هسته های پایدار برای طول چرخه توسعه فعلی حفظ می شوند. پس از اینکه لینوس یک هسته جدید منتشر کرد، درخت انتشار هسته پایدار قبلی متوقف می شود و کاربران باید به هسته منتشر شده جدیدتر حرکت کنند.
هسته های پایدار بلند مدت
پس از گذشت یک سال از این فرآیند انتشار پایدار جدید، مشخص شد که بسیاری از کاربران مختلف لینوکس میخواهند یک هسته برای بیش از چند ماه پشتیبانی شود. در پاسخ، انتشار هسته با پشتیبانی طولانی مدت (LTS) ایجاد شد، با اولین هسته LTS (2.6.16) در سال 2006 منتشر شد. از آن زمان، یک کرنل جدید LTS یک بار در سال انتخاب می شود و جامعه هسته آن هسته را برای یک زمان حفظ می کند. حداقل 2 سال
در زمان نگارش این مقاله، هسته های LTS نسخه های 4.4.y، 4.9.y، 4.14.y، 4.19.y، 5.4.y و 5.10.y هستند. یک هسته جدید هر هفته منتشر می شود. به دلیل نیازهای برخی از کاربران و توزیعها، چند هسته قدیمی دیگر توسط توسعهدهندگان هسته با چرخه انتشار کندتر نگهداری میشوند. اطلاعات مربوط به تمام هستههای پایدار بلندمدت، مسئول آنها و مدت زمان نگهداری آنها را میتوانید در صفحه انتشارات kernel.org بیابید.
هسته LTS به طور متوسط روزانه 6-8 وصله پذیرفته شده منتشر می کند، در حالی که نسخه های معمولی هسته پایدار حاوی 10-15 وصله در روز هستند. تعداد وصله ها در هر نسخه با توجه به زمان فعلی انتشار هسته توسعه مربوطه و سایر متغیرهای خارجی در نوسان است. هر چه یک هسته LTS قدیمی تر باشد، وصله های کمتری برای آن اعمال می شود زیرا بسیاری از رفع اشکالات اخیر مربوط به هسته های قدیمی تر نیستند. با این حال، هر چه یک هسته قدیمیتر باشد، به دلیل تغییرات در پایگاه کد، پشتیبانگیری تغییراتی که برای اعمال لازم است، سختتر است. بنابراین در حالی که ممکن است تعداد وصلههای کلی کمتری اعمال شود، تلاش برای حفظ یک هسته LTS بیشتر از حفظ هسته پایدار معمولی است.
قوانین وصله هسته پایدار
قوانین مربوط به مواردی که می توان به نسخه هسته پایدار اضافه کرد از زمان معرفی تقریباً یکسان باقی مانده است و در زیر خلاصه می شود:
باید آشکارا درست و آزمایش شده باشد.
نباید بزرگتر از 100 خط باشد.
فقط یک چیز را باید اصلاح کرد
باید مشکلی را که گزارش شده است برطرف کند.
میتواند یک شناسه دستگاه جدید یا خصلت سختافزاری باشد، اما قابلیتهای عمده جدیدی را اضافه نکند.
باید قبلاً در درخت لینوس توروالدز ادغام شده باشد.
آخرین قانون، "باید قبلاً در درخت لینوس توروالدز ادغام شود"، از از دست دادن اصلاحات توسط جامعه هسته جلوگیری می کند. جامعه هرگز نمیخواهد یک اصلاحیه برای انتشار هسته پایداری که قبلاً در درخت لینوس توروالدز وجود ندارد، انجام دهد، بنابراین هرکسی که ارتقا میدهد هرگز رگرسیون را مشاهده نکند. این امر از بسیاری از مشکلاتی که سایر پروژه هایی که دارای یک شاخه پایدار و توسعه هستند جلوگیری می کند.
به روز رسانی هسته
جامعه هسته لینوکس به پایگاه کاربری خود قول داده است که هیچ ارتقایی هرگز چیزی را که در نسخه قبلی کار می کند، خراب نمی کند. این وعده تا امروز هم پابرجاست. رگرسیونها اتفاق میافتند، اما آنها باگهای دارای بالاترین اولویت هستند و یا به سرعت برطرف میشوند، یا تغییری که باعث رگرسیون شده است به سرعت از درخت هسته لینوکس برگردانده میشود.
این وعده هم برای بهروزرسانیهای تدریجی هسته پایدار و هم برای بهروزرسانیهای بزرگتر که هر سه ماه یکبار اتفاق میافتد صادق است. با این حال، جامعه هسته فقط می تواند این قول را برای کدهایی که در درخت کرنل لینوکس ادغام شده است، بدهد. هر کدی که در هسته دستگاهی که در نسخههای kernel.org نیست ادغام شود ناشناخته است و هرگز نمیتوان تعامل با آن را برنامهریزی کرد یا حتی در نظر گرفت.
دستگاههای مبتنی بر لینوکس که دارای مجموعههای وصله بزرگ هستند، میتوانند هنگام بهروزرسانی به هستههای جدیدتر، به دلیل تعداد زیاد تغییرات بین هر نسخه (10-14 هزار تغییر در هر نسخه) با مشکلات اساسی مواجه شوند. پچستهای SoC بهخاطر اندازه بزرگ و تغییرات سنگین در معماری خاص و گاهی اوقات کد هسته اصلی، بهخاطر مشکلاتی در بهروزرسانی به هستههای جدیدتر شناخته میشوند. در نتیجه، اکثر فروشندگان SoC شروع به استانداردسازی استفاده از نسخه های LTS برای دستگاه های خود کرده اند و این دستگاه ها را قادر می سازد تا باگ ها و به روز رسانی های امنیتی را مستقیماً از جامعه هسته لینوکس دریافت کنند.
امنیت
هنگام انجام انتشار هسته، جامعه هسته لینوکس تقریباً هرگز تغییرات خاصی را به عنوان اصلاحات امنیتی اعلام نمی کند. این به دلیل مشکل اساسی مشکل در تعیین اینکه آیا یک رفع اشکال در زمان ایجاد یک رفع امنیتی است یا خیر است. همچنین، بسیاری از رفع اشکالها تنها پس از گذشت زمان طولانی مشخص میشوند که مرتبط با امنیت هستند، بنابراین جامعه هسته اکیداً توصیه میکند که همیشه تمام رفع اشکالهایی که منتشر میشوند را انجام دهید.
هنگامی که مشکلات امنیتی به جامعه هسته گزارش می شود، در اسرع وقت برطرف می شوند و به صورت عمومی به درخت توسعه و انتشارات پایدار منتقل می شوند. همانطور که در بالا توضیح داده شد، تغییرات تقریباً هرگز به عنوان یک "اصلاح امنیتی" توصیف نمی شوند، بلکه مانند سایر رفع اشکال برای هسته هستند. این کار به این منظور انجام میشود که به طرفهای آسیبدیده این امکان را میدهد که سیستمهای خود را قبل از اینکه گزارشکننده مشکل اعلام کند، بهروزرسانی کنند.
برای جزئیات در مورد گزارش اشکالات امنیتی به جامعه هسته برای رفع و رفع آنها در اسرع وقت، به اشکالات امنیتی در راهنمای کاربر و مدیر کرنل لینوکس در www.kernel.org مراجعه کنید.
از آنجایی که باگهای امنیتی توسط تیم هسته به عموم اعلام نمیشوند، اعداد CVE برای مسائل مربوط به هسته لینوکس معمولاً هفتهها، ماهها و گاهی سالها پس از ادغام اصلاح در شاخههای پایدار و توسعه منتشر میشوند.
یک سیستم امن نگه دارید
هنگام استقرار دستگاهی که از لینوکس استفاده میکند، ما قویاً توصیه میکنیم که تمام بهروزرسانیهای هسته LTS توسط سازنده گرفته شده و پس از آزمایش مناسب نشان میدهد که بهروزرسانی بهخوبی کار میکند، برای کاربرانش ارسال شود. این چند مزیت دارد:
نسخه ها توسط توسعه دهندگان هسته به طور کلی بررسی شده اند، نه در بخش های جداگانه.
تعیین اینکه کدام وصلهها مشکلات «امنیتی» را برطرف میکنند و کدام نه، دشوار است. تقریباً هر نسخه LTS حاوی حداقل یک اصلاح امنیتی شناخته شده است و بسیاری از آنها هنوز "ناشناخته" هستند.
اگر آزمایش مشکلی را نشان دهد، جامعه توسعهدهنده هسته به سرعت واکنش نشان میدهد تا مشکل را حل کند.
تلاش برای فیلتر کردن تنها تغییراتی که اجرا می کنید منجر به درخت هسته ای می شود که ادغام صحیح آن با نسخه های بالادستی آینده غیرممکن است.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]