Release Candidate.
Wenn ein Update für ein Programm fast fertig ist, erhält die Testversion per Konvention eine rc-Nummer. Wenn kritische Fehler gefunden werden, die behoben werden müssen, wird das Programm aktualisiert und mit einer höheren RC-Nummer neu aufgelegt. Wenn keine kritischen Fehler mehr vorhanden sind oder keine weiteren kritischen Fehler gefunden werden, wird die rc-Bezeichnung gelöscht.
Der aktuelle Linux-Release-Zyklus funktioniert wie folgt:Angenommen, 3.7 wird heute veröffentlicht, was etwa 2 Wochen "Merge-Fenster" öffnet (Linus akzeptiert neue Funktionen, die anderswo ausprobiert wurden, in experimentellen Bäumen; die meisten Aktivitäten, die zu 3.8 führen, finden hier statt ). Linus veröffentlicht 3.8-rc1 und schließt das Zusammenführungsfenster offiziell, danach akzeptiert er nur noch (fast) Fehlerbehebungen für das, was zusammengeführt wurde. Manchmal wird zusammengeführtes Zeug wieder herausgenommen, selten findet neues Zeug den Weg in den Kernel. Ungefähr jede Woche veröffentlicht Linus 3.8-rc2, -rc3, ... und fährt fort, bis er zufrieden ist, dass es keine neuen Fehler gibt, und veröffentlicht 3.8. Dann beginnt der Kreislauf von neuem. Der Zyklus dauert ungefähr 8 Wochen, also geht es bis zu rc6 oder so, aber manchmal ist der Zeitraum zwischen rcs verkürzt, manchmal verlängern hartnäckige Fehler den gesamten Zyklus.
Nachdem 3.8 veröffentlicht wurde, wird es vom stabilen Team übernommen, das Fehlerkorrekturen für schwerwiegende Probleme und minimale Auswirkungen sammelt und 3.8.1, 3.8.2, ... veröffentlicht. Dafür gibt es keinen festen Zeitrahmen, und sobald 3.9 kommt draußen gibt es kein 3.8.x mehr.
Es gibt auch Longtime-Support-Versionen, meistens zu Gunsten (und unter Betreuer) der Unternehmensdistributionen oder Personen im Embedded-Bereich, derzeit einigermaßen gepflegt sind 2.6.32.60 und 2.6.34.14 (alter Nummerierungsstil), 3.0.63, 3.2.38, 3.4.30.