A kernelfejlesztő az alábbi sémára tett javaslatot. A fejlesztők nevezzék el a kernelt az aktuális év után, majd tegyék utána a kernelszámozást az alábbiak szerint:
ÉV.SZÁM.KISEBB_KIADÁS
Példaként, a jövő évtől kezdve ez így nézne ki:
A 2009-es első kiadás száma:
2009.0.0
A másodiké:
2009.1.0
Ha nem szeretnének 0-val kezdődő verziószámozással foglalkozni, akkor kezdhetnék a számozást "0" helyett "1"-gyel:
Első kiadás:
2009.1.0
A második:
2009.2.0
A -stable kiadások pedig növelhetnék a "KISEBB_KIADÁS" (MINOR_RELEASE) számot az alábbiak szerint:
Az első -stable kiadás száma:
2009.1.1
A másodiké:
2009.1.2
és így tovább.
A részletek és a többi kernelfejlesztő véleménye ebben a szálban olvasható.
- A hozzászóláshoz be kell jelentkezni
- 3498 megtekintés
Hozzászólások
nekem ez (x.y) tetszik, bár igazából tökmindegy (nekem), hogy mi a verziószámozási séma. egyébként ebből a szálból nem igazán derül ki, hogy miért is oly nagy fájdalom gregnek a mostani séma, és miért lesz kisebb fájdalom egy új
- A hozzászóláshoz be kell jelentkezni
Bár csak mezei user vagyok, de nem értek egyet a tervezett változtatással.
Ezt a számozási rendszert azon dusztribucióknál érdemes használni (Ubuntu, Mandriva, etc), melyek minden évben egy vagy több kibocsátással rendelkeznek. A Debian-nál évjárattól függetlenül a fő kibocsátás időszakos kiegészítései - javításai vannak.
Kernel esetén logikai számozás van, szintén független az évjárattól. Esetleg az x.y.z számozás mögé zárójelben lehetne kiírni a dátumot.
CSZ
- A hozzászóláshoz be kell jelentkezni
Én speciel csak eltüntetném előle a 2-est.
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"
- A hozzászóláshoz be kell jelentkezni
"Jobb Solarist csinálunk a Linuxból, mint a Solaris!"
Vagy mi.
--
SUN? Umm, No.
- A hozzászóláshoz be kell jelentkezni
En nem, amennyiben belathato idon belul erkezik a 3-as. :)
--
Bárki aki aritmetikai módszerekkel akar előállítani egy véletlen számot, az a bűn állapotában leledzik.
- A hozzászóláshoz be kell jelentkezni
és így van?
egyáltalán, milyen milestone-ok voltak az okai az eddigi 0.x-->1.x-->2.x váltásoknak?
—-—-—
int getRandomNumber() {
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
Én meg visszatérnék a jó öreg x.y.z számozásra, ahol ha y páros akkor stable, ha páratlan akkor fejlesztői.
Bár biztos volt róla szó, én ezt nem értem hogy ezzel mi volt a baj.
- A hozzászóláshoz be kell jelentkezni
pluszegy.
amugy miért szunt meg a régi módi?
- A hozzászóláshoz be kell jelentkezni
Mert régimódi volt. ;)
--
SUN? Umm, No.
- A hozzászóláshoz be kell jelentkezni
Az hogy régimódi nem értem hogy miért indok! Csak azért mert valami régi nem cserélem le, ha amúgy jól bevált.
- A hozzászóláshoz be kell jelentkezni
Mert nagyon kevesen nyúzták a devel ágat -- most van egy develunstablestable...szomtudja ág, amiben 2.3.4-rc5.11-pre23-mz/x formátumban számozódnak a verziók :-P
- A hozzászóláshoz be kell jelentkezni
Ha jól emlékszem az olvasottakra, a 2.6.8-nál volt egy bug, amit gyorsan javítottak, azonban ez nem volt akkora, hogy 2.6.9-nek nevezzék, így lett 2.6.8.1, ez lett hivatalos a 2.6.11-től.
----------------------------------------------
"Lehet egy kérdéssel több?" (Egri János)
- A hozzászóláshoz be kell jelentkezni
Spec, figyelembe véve, hogy hogy fejlesztik most, szimplán indíthatnák 3.0.0 -ról a következőt, ahol a 2.6 -> 3 lenne.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
És így lesz a 2009.3-rc8 után 2010.0 stabil... :) Már legalábbis ha átcsúszik következő évre. Na ez az, ami sokkal zavaróbb lesz, mint a jelenlegi számozás.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ez nagyon meggyozo ellenerv. Nem lehet tudni, hogy mi lesz a kovetkezo rszmag valtozatszama.
A kiadas elott majd igy irjak rola a cikkeket: "a 2009.4, illetve ha atcsuszik a kovetkezo evre a kiadas idopontja, a 2010.0 szamu rszmagban ... ".
Meg az sem segit, ha nem a kiadas, hanem a szuletes/elkezdes idopontjanak evet kapja meg.
Fel evvel kesobb olvasva is zavaro.
- A hozzászóláshoz be kell jelentkezni
következő levél eleje:
"pick a name when the merge window opens"
- A hozzászóláshoz be kell jelentkezni
A Linux kernel developzorz summit helyszínei, esetleg a népszerűbb kocsmák elhelyezkedése, neve után lehetne kódneveket gyártani, mint a Windowsnál.
Esetleg jövőre tarthatnák Budapesten is a rendezvényt, így a következő kerneleket hívhatnák:
- Piszkos Frednek
- Aranysasnak
- Libellának
- Kaltenbergnek
esetleg Mélypontnak.
--
SUN? Umm, No.
- A hozzászóláshoz be kell jelentkezni
+1. Mióta van itt nálunk a faluban retró kajálda, inkább oda járok, mint az ~50 éve változatlan bíróságra. Persze ez (s|n)em tartozik ide, de wtfc.
- A hozzászóláshoz be kell jelentkezni
Es minden stable release mindig masik varos kocsmaibol venne a neveket.
Minel stabilabb, annal puccosabb hely neve lenne.
Pl:
linux-kernel-2.77.7-Debrecen-ibolya
linux-kernel-2.77.9-Debrecen-kikoto
.
.
.
linux-kernel-2.78.1-Debrecen-szaxofon
na?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Evszamot minek ? Nem tetszik, ne legyen koze az evnek a kernel szamozashoz.
Es nevet adni is felesleges.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Praktikusnak praktikus, de nekem nincs problémám ezzel a számozással sem.
- A hozzászóláshoz be kell jelentkezni
Egyetértek. Az évszámozás is lehet jó bizonyos esetekben (pl. Ubuntu), de ez a kernel fejlesztésre pont nem igaz. Ez főleg évfordulókkor keserítené meg a kernelfejlesztők és használók életét. Bár, ha át tudnának térni fix kiadási ciklusra, akkor lehet jó, de annak meg más hátulütői vannak.
- A hozzászóláshoz be kell jelentkezni
Hát a fix kiadás az a legnagyobb baromság... lásd. pl Mandriva 2009, tele van hibákkal. Mint a jelenlegi kernelek...
Ha kernelfejelsztő lennék, döntési joggal, addig nem engednék új funkciót, amíg az összes ismert hiba, regresszió stb. javításra nem kerül. Aztán lehet folytatni.
- A hozzászóláshoz be kell jelentkezni
Szerinted mennyi ideig tartó kódfagyasztás lenne ebből? Aztán meg lehetne megint loholni a hardverek fejlődése után...
- A hozzászóláshoz be kell jelentkezni
Mondjuk az igaz, de talán nem kellet volna megvárni, míg ennyi szar felgyűlik a lefolyóban...
Másrészt miért nem lehet elválasztani a driver és a kernel fejlesztést?
- A hozzászóláshoz be kell jelentkezni
Talán mert a kernel API kőbevésett volta minimum kétséges... Szerintem...
- A hozzászóláshoz be kell jelentkezni
Ez így van...nyílván nem lehet megoldani amit írtam, csak egyfajta költői kérdésnek szántam.
- A hozzászóláshoz be kell jelentkezni
van nekünk hosszú karbantartású kernelünk, med debian-unk. Tudom hogy nem fedi teljesen a kívánságod, de azzal piszok lassú lenne a fejlődés.
Németh Ákos [sokahtemen] http://fedoralinux.hu/ --A magyar Fedora klub
- A hozzászóláshoz be kell jelentkezni
Megjelent a Gentoo Linux 2010.0, benne a Linux kernel 2010.255.255, Portage 2010.2.2.9.9, Xfce 2009.4.4.9, glibc 2009.2.8.1 és a gcc 2008.4.1.2.
- A hozzászóláshoz be kell jelentkezni
'Valtsa valora On is Greg K-H almat!'
- A hozzászóláshoz be kell jelentkezni
Próbáltam pingelni ezeket a címeket IPv6-on, de egyik se felel. :)
--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.
- A hozzászóláshoz be kell jelentkezni
Szerintem egyszerűen csak szerepelni akar GKH. :)
- A hozzászóláshoz be kell jelentkezni
Vihar egy kanál biliben.
--------------
r=1 vagyok, de ugatok...
- A hozzászóláshoz be kell jelentkezni
Pontosan. A kernel számozásának megváltoztatása ráadásul visszafelé nem is lenne kompatibilis. A 2.6.27-es kernelt felváltja mondjuk a 2009.0.1. Roppant zavaró lenne.
- A hozzászóláshoz be kell jelentkezni
vagy csak egy terelés, a e1000e által keltett szaralinux viharnak, és így nem a fatális hibáról beszélnek az emberek, hanem csak az értelmetlen dolgokról, mert teljesen egal, hogy milyen verzió, így is, úgy is szar lesz...
___
info
- A hozzászóláshoz be kell jelentkezni