Jöhet a 6.0-s Linux kernel

Kernel

Tegnap megjelent az 5.19-es Linux kernel, aminek a bejelentésében Linus elejtette, hogy a következő kernel a 6.0-s lesz ☝‍️

( persicsb | 2022. 08. 02., k – 11:06 )

Mivel a verziószám semmilyen technikai információt nem hordoz (kompatibilitás stb.), ezért hívhatnák kódnevekkel is. Például ez lehetne a Kisnyúl Edition.

Pusztan datumbol nem fogod tudni, hogy az az 5.4.19-es vagy az 5.17.2-esnek felel meg.

Nem teljesen felel meg semver-nek ez igaz, de az se biztos hogy jobb lenne ha 2.99.3 -nak hivnank, ha jol szamolok most ott tartanank, mivel major verziot gyakorlatilag sose valtanak.
Nem lenne jobb eroltetetten ravenni hogy legyen major verzio valtas es valami nem indokolt de kenyszeresen belerakott breaking change miatt megfeleljen semver-nek, csak hogy neha valtsunk foverziot is.
Igazabol kernelnel amig nem lesz tenyleges komoly breking change addig nem sok jelentosege lesz hogy 2.167-nek vagy 8.13-nak hivjak, max utobbi kevesebb szammal leirhato meg talan emberileg konnyebben kovetheto mert igy 20 verzionkent van egy kis hirveres hogy megint valtozik az elso szam es arra talan jobban felfigyel az ember, minthogy kijott a 174. verzio

Pusztan datumbol nem fogod tudni, hogy az az 5.4.19-es vagy az 5.17.2-esnek felel meg.

És kellene? :)

Mármint nyilván ilyenkor nincs dátum és verziószám, csak "dátum-build", és hasonlók.

Nem teljesen felel meg semver-nek ez igaz

Nem is kell, pont azt írtam, hogy nem kell egy az egyben átvenni azt a szisztémát. :)

Igaza van, kellene, hogy kiderüljön. Megint más, hogy ez a mostani visszaportolós, visszaszámozós gyakorlat is rossz. Nem is olyan régi időkig, míg a 2.6-os kernel is támogatott volt, mentek még ilyen 2.6.138+ kernelek, na, arról ránézésre lehetett hinni, hogy hú de régi, közben meg minden vissza volt patchelve. Nagyon zavaró, fórumokon is olvastam több embert, akik megtévedtek, pl. NVMe támogatásnál, azt hitték, hogy a 2.6.x miatt nem megy, közben meg vissza volt bele portolva.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Szerintem ezt a problémát nem a verziószámokon keresztül lehet megoldani. Ha van egy vKiskutya, amiben van A, B és C feature, és van egy régebbi, vKismacska, amiben csak A feature van, és a vKiskutyából a vKismacskába portolják C feature-t, akkor pontosan ugyanaz történik, mint most:

  • a verziószámból nem derül ki, hogy melyik feature melyik verzióval került be
  • a verziószámból nem derül ki, hogy melyik feature-t hova backportolták

Sőt, továbbmegyek: ebben a konkrét esetben, a kernel verziózási szokásait ismerve (túl magas lett a minor verzió, inkrementáljuk eggyel a majort lol) az egyetlen verziójelölés, ami hordoz is magában valamilyen implicit jelentést az a dátum. A többi lényegében egy tetszőleges string, lehetne az, is a szokás, hogy minden második verzió állatnevet kapjon, és akkor mondjuk az 5.17.32 után jöhetne a Happy Hippo, utána meg a 6.0.0. :)

Nem csak feature-t lehet backportolni sokszor nem is azt szoktak, hanem bugfixet meg security fixet. Abban az esetben pedig igenis hasznos hogy tudom pl 5.17-es verzioban kerult bele az a feature amire szuksegem van, ujabbak nem erdekelnek de azt a verziot erinto javitasok igen igy 5.17.x-nel lehetoleg legyen az x egy friss verzio. Ezt a pusztan datumozott verziobol nem derited ki.

Egyebkent semver resze hogy megadhatsz build informaciokat '+' jel utan, ami nem valtoztat a verzioszam kezelesen az alkalmazasokban ellenben beleirhatod peldaul a datumot: 5.17.23+20220813110313.

Nem csak feature-t lehet backportolni sokszor nem is azt szoktak, hanem bugfixet meg security fixet

Ebben a kontextusban bármilyen a feature lehet bármilyen code change, de persze, bármit lehet backportolni.

Ezt a pusztan datumozott verziobol nem derited ki.

Pusztán a semverből kiderül? :)

Pont ezt írtam, hogy a mi lett backportolva kérdésre nem ad választ egyik forma sem, ezt a problémát másik szinten kell kezelni. Van egy appom, szigorúan semver szerint verziózva a sok publikus interface miatt, most tart a 2.1.x környékén, meg tudod mondani, hogy egy bizonyos bugfix backportolva lett-e az 1.3.1-be? Szerintem amíg nem adom oda a release notes-ot, addig nem.

Ugyanezen logika szerint, ha a 2022.08.01-build1 verzióban behozok egy bugfixet, simán visszaportolhatom a 2021.12.01-build4-be.

Megelőzendő egy felesleges kört, természetesen van létjogosultsága mindkét formátumnak:
#include https://hup.hu/comment/2815399#comment-2815399

Pusztan datumbol nem fogod tudni, hogy az az 5.4.19-es vagy az 5.17.2-esnek felel meg.

Miben másabb az, hogy azt mondom, hogy 14536-os kernelverzió, ahelyett, hogy 5.4.19?

Van mondjuk két kernelverziód, 10436 és 14567, a két szám pont ugyanannyira bír mondanivalóval, mint az, hogy 5.4.19 és 5.17.2, mivel semmiféle kompatibilitási/inkompatibilitási információt nem tartalmaz az sem, hogy 5.4.19 és 5.17.2.

Azert ez igy nem igaz, pl. az 5.4.19 az az 5.4-nek a 19. patch release, az 5.17.2 az meg a 5.17.2-nek a 2. patch release, a monoton novekvo szam minden uj release eseten nem tartalmaz ilyen infot. Az hogy a 5.4.19 es 5.17.2 semmifele kompatibilitasi infot nem tartalmaz meg nem igaz, patch releasebe inkabb csak kisebb bugfixek meg fontos backportok szoktak belekerulni, pl. user namespace-ben overlayfs-t root nelkul 5.11 ota lehet csinalni, ergo 5.4.19-ben nem fog mukodni es 5.17.2-ben meg igen (igen, emiatt kellett az egyik gepemet updatelnem anno valami 5.4.sok-rol, mert ott nem volt).

Aminek nincs ertelme jelenleg az az elso ket verzio szam. 5.4.19 helyett lehetne 53.19 es 5.17.2 helyett 66.2, nem lenne kisebb informacio tartalma (csak jobban hasonlitana egy browser verziora). Mondjuk a kedvencem az idiota verzioszamozasra tovabbra is a ruby, az 1.9 kb minden korabbi kodot elrontott, az utana jovo 2.0 meg majdhogynem teljesen backward compatible volt. A 2.7 utan meg 3.0 jott, csak hogy ne hogy azt hidd hogy a verzioszam az igazabol csak egy decimalis szam egy ponttal a ket szamjegy kozott, mikozben semmivel nem volt benne tobb breaking change mint a korabbi verzioknal.

I hate myself, because I'm not open-source.

"ergo 5.4.19-ben nem fog mukodni es 5.17.2-ben meg igen"

Nem tudhatod, hogy nem fog működni, backportolhatták egy alverzióban ezt akár. Sőt, 5.17-ben meg ki is vezethették, hiába van benne 5.11-ben.

Például hiába volt 5.13-ban IDE támogatás, ez az 5.14-ben kikerült, és a libATA hatáskörébe tartozik már.

Pont ezért nem jelent semmit a verziószám.

Jo, ennyi erovel semmi verzioszamnak nincs ertelme, es csak git commit sha1-eket kene hasznalni.

Viszonylag keves olyan szoftver van amibol soha nem vesznek ki semmi featuret, varazsgomb vagy idogep nelkul meg eleg nehez megmondani elore hogy ez mikor fog bekovetkezni (itt meg a semver se segit, mert a major verzio noveles azt jelenti hogy van backward incompatible change, nem azt hogy minden egyes feature valtozott vagy kihuztak). Ha majd teszem azt linux 8.13-ban kihuzzak az en altalam emlitett featuret, akkor majd azt lehet mondani hogy 5.11 es 8.12 kozott mukodott, a 8.12.14-ben meg a 6.11.145-ben benne lesz, 8.12.13-ban meg 8.17.2-ben nem (ha csak nem talaljak ki menet kozben hogy megis kell a feature...). (Illetve az az IDE tamogatas amirol beszelsz meg ezer eve deprecated volt mar, szerintem senkit nem ert varatlanul hogy egyszer vegre kidobtak.)

Backportok teny hogy neha be tudnak kavarni, de azert egy 5.4.0 meg 5.4.19 99%-ban ugyan az, meg egy 5.4 meg 5.17 kozott joval nagyobb valtozasok lesznek. Jelentosebb architekturalis valtozasokat nem szoktak backportolni. Meg ugye lehet olyan is hogy egy feature benne van 5.12.13-ban, 5.12.14-ben es 5.12.15-ben is, de 5.12.14-ben van egy bug amitol teljesen hasznalhatatalan, akkor ezt most vegyuk ugy hogy arra az egy verziora kihuztak a supportot?

I hate myself, because I'm not open-source.

A kódnév még rosszabb, mert abból a sorrend sem derül ki. A legjobb rendszer ma már ebben a felgyorsult fejlesztési ütemben az ÉÉÉÉ.H(.patchverzió) számozás lenne, mert abból kiderül milyen régi, akár támogatási időt is lehetne számolni.

Persze az a hagyományos számozás se rossz, hogy a főverziót csak jelentős átírásnál, API változásnál vezetnek be, addig csak alverziót léptetnek, de ez csak következetesen működik. Így, ilyen önkényesen, ahogy Torvalds csinálja, nincs értelme. Valahogy ezek a verziószámozós sémák nem az erőssége, az a páros-páratlen verziózás még a 2.x-es korszakból még nagyobb agyrém volt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( DirtY_iCE | 2022. 08. 02., k – 11:26 )

Lassan azon lehet aggodni, hogy mi lesz amikor mar a major number is tul nagy lesz.

I hate myself, because I'm not open-source.

( YleGreg | 2022. 08. 02., k – 13:02 )

Nagyon batorkodik a ficko, de majd az ispan deresre huzatja a varmegyehazan, oszt ket bot utan meglatjuk, hogy meri-e tagadni, hogy arab szammal irta a nyugati posvany hatos szamat, az istenfelo nemzeti feltucat helyett! Aztateremburajat az ilyennek.