Linux 5.0-rc1 (diskuse)

[paralen]

Nelogicke cislovanie. To radsej mali prejst na styl Chrome / Firefox, kde kazde nove vydanie ma inkrementovane cislo. Alebo major.minor.bugfix ako bolo kedysi.

[pushkin]

A není to jedno? Vždyť je to jenom číslo...

[xhc]

isteže by to bolo číslo, z ktorého by sa ale dalo vyčítať viacej, než len číslo

[Käyttäjä 11133]

Co by se dalo vyčíst z čísla jako má Chrome, nebo Firefox víc, než se dá vyčíst teď?

[xhc]

ja by som bol ale za staru dobru klasiku major.minor.bugfix

[lertimir]

Jenže u jádra není žádný major.minor.bugfix. takové uspořádání předpokládá, že se v jedné chvíli pracuje na nějaké nové Major verzi, která je "nová a lepší", v současné verzi se pracuje na postupných vylepšeních minor a současně se řeší bugfixy. Poslední major verze byla verze 2.0 v roce tuším 96. po verzi 1.3.100. Pak se vyvinuly postupně verze 2.4 a 2.6 jakožto minor verze duležité pro další vývoj. Verze 2.4 začíná v roce 01 a poslední verze, který má definovaný changelog 2.4.31 z roku 05 ale úplně poslední je 2.4.37.9. Verze 2.6 začíná v prosinci 03. a končí verzí 2.6.39 v roce 11, kdy se Linus naštval, argumentoval že 2.6 je fakticky bez jakéhokoliv významu, protože se nic v tom nezmění, že na jádře je kontinuální vývoj a major.minor vývoj a přečísloval další verzi na 3.0 s tím že se budou releasy číslovat v jako minor číslo do 20 (končílo 3.19) a pak se zvedne major. V major.minor bychom byli někde na 2.6.80, protože to co je, je pořád jádro 2.6 vyvinuté postupnou změnou, nebyl žádný major přechod.

[Michal Kubeček]

Trochu bych to upřesnil. Původní model počítal s tím, že současně budou existovat dvě "živé" řady, jedna "stabilní" (např. 1.2.y nebo 2.4.y) a jedna "vývojová" (např. 1.3.y nebo 2.5.y). Myšlenka byla, že do stabilní řady půjdou jen opravy chyb, zatímco nové věci a větší změny se budou testovat ve "vývojové" řadě, ze které pak po nějaké stabilizační fázi vznikne nová stabilní.

Problém byl, že takhle to skutečně fungovalo naposledy u řady 1.2.y, vývoj 1.3.y se táhnul tak dlouho, že uživatelé nemohli nebo nechtěli čekat na nové funkce a drivery, takže nakonec většina používala buď přímo řadu 1.3.y (která to dotáhla až někam ke stovce) nebo distribuční jádro z ní odvozené. S každou další řadou pak ten původní model fungoval méně a méně, až se Linus rozhodl řadu 2.7.y vůbec nezačít a místo toho pokračovat s vývojem přímo ve 2.6.y. Roli původních "stabilních řad" potom převzaly Gregovy 2.6.y.z. Ne náhodou tahle změna časově víceméně odpovídá přechodu na skutečně použitelný verzovací systém (nejdřív BitKeeper, později git).

Změna z 2.6.y/2.6.y.z na 3.x/3.x.y byla víceméně kosmetická záležitost (která ovšem rozbila hromadu skriptů), v novém modelu přestalo mít smysl rozlišovat major verze. Přechod na 4.x a 5.x byl už vysloveně dán jen tím, že se Linusovi zrovna chtělo. Teoreticky by samozřejmě bylo možné zrušit dvouúrovňové číslování úplně, ale Linus očividně není fandou příliš velkých čísel verzí - a abych pravdu řekl, vůbec mi to nevadí.

[pushkin]

Líp bych to nenapsal...

[xhc]

LTS ?

[ewew]

Alebo format : Linux X.datum.poradie.

[xhc]

+ lts niekam

[Peter Golis]

Tak to navrhnite Linusovi, možno sa na to pozrie keď sa vráti z dovolenky. Vám dvom určite urobí čo vám uvidí na očiach, a kvôli tomu aj zmení zaužívané zvyky. Kontakt naňho predsa máte obaja.

[ewew]

Odpoviem stručne. Mne je jedno aké bude označovanie. Podstatne je ako sa rozhodne autor. I keď preferujem súčasne riešenie.

[Peter Golis]

Tak s tým si ten názor mohol zabaliť do irónie

[Peter Golis]

Nebolo by teda lepšie keby sa verzia jadra označovala pomocou automaticky generovaného 64bit UUID?

[Michal Kubeček]

Jako že by nebylo z označení verzí poznat, která je novější? Tak to by bylo velmi praktické…

[Peter Golis]

Keď mu nevyhovoval súčasný model, tak som navrhol novší a jednoduchší. I keď tá jednoduchosť je na úkor prehľadnosti.

[Käyttäjä 11133]

Jenže tvůj návrh by měl vliv na solvery v package manageru a v tom je ten hlavní problém, nemůžeš porovnat který je větší, nebo menší; dokud je to "nějaká porovnatelná sekvence" tak je to většině jedno, to ale o tvém návrhu říci nelze.

[Peter Golis]

Vysvetli mi prečo by nemohol ten UUID korešpondovať s časom.

[rich]

Vysvetli mi prečo by nemohol ten UUID korešpondovať s časom.

Tak mozna si to mel rict hned na zacatku.
Nicmene potom by ale uplne stacil jen ten cas, plus treba jeste datum a zadne UUID se nemusi generovat...
Neco jako RHEL 20190107_1616

[Peter Golis]

To by malo ovšem moc prehľadný formát, skoro ako je to teraz. A to nevyhovovalo užívateľovi xhc, tak som špeciálne preňho navrhol niečo čo vyzerá odbornejšie. Spodobovanie hlások p a b tu hrá rolu.

[pushkin]

A není lepší mít 4.15, kde jsi schopen si zapamatovat alespoň to, že máš jádro ze čtyřkové řady, než mít jádro 2.6.76 (kde bychom zhruba aktuálně byli). Nebo ještě hůře po vzoru Chromu mít jádro 76.0.58.2668761, což je číslo, ze kterého tušíš úplný ho...?

Prostě je to jenom číslo. Je poměrně ergonomické a nevidím v tom problém. Jediný, kdo s tím měl problémy byl ANSYS, který v době vydání jádra 3.x testoval přítomnost jádra 2.6.x a bylo nutno mu upravovat instalační skripty (t)lamě

[Strycek Fritzl]

Vek je taky jenom cislo a co je s tim mrzeni

[lazywriter]

Když vidím kolik problému udělalo přečíslování u Postgresu a to tam přešli jenom z major.minor.patch na major.minor, tak bych doporučoval nic neměnit. Kór u jádra.

[Odin]

Já tu změnu vítám. Ty verze 4.x zaváněly homosexualismem a propagací čtyřprocentní menšiny. Když k tomu připočtu ještě CoC aféry v nedávné době, tak je to celkem jasné. Jsem rád, že se věci konečně vrací do normálu.

[a1bert]

ja bych byl s tim optimismem opatrnej, podle poslednich kuloarovych informaci, se suma jedincu 4% mensiny zacina blizit 5%

[lertimir]

Jaderní vývojáři na to pamatují a už s předstihem zadefinovali adresář pro 6% (verzi 6.x)