Nazewnictwo jądra Linuksa jak w Ubuntu?
16 lipca 2008, KrzysieQ
Linus Torvalds zastanawia się nad zmianą sposobu oznaczania nowych wydań jądra Linuksa na schemat ROK.MIESIĄC, podobnie jak ma to miejsce m.in. w dystrybucji Ubuntu. Obecny system uważa za zbyt skomplikowany i utrudniający zorientowanie się w numeracji kolejnych wersji jądra.
Jak czytamy na PCWorld.pl:
Już w 2004 roku zrezygnowano z modelu, w którym na zmianę pojawiały się wydania niestabilne (np. 2.1.x, 2.3.x itp.) oraz stabilne (2.2.x, 2.4.x itp.). W chwili obecnej wersje niestabilne “przytrafiają się” pomiędzy kolejnymi Linuksami 2.6.x, które z założenia powinny gwarantować pełną przewidywalność.
Jednak Torvalds zastanawia się nad porzuceniem również obecnego sposobu numerowania. Jego zdaniem publikacja kolejnych wersji sprawi, że w końcu przestaniemy odróżniać zbyt duże liczby.
Więcej informacji w języku angielskim znajdziecie w tekście: Kernel Release Numbering Redux.
Mnie się tam ten nowy system średnio podoba. Obecny jest w miarę przewidywalny – jeśli w schemacie x.y.zz.źź parzyste liczby są na pozycjach ‘y’ i ‘zz’, kernel jest stabilny.
Nie byłoby prościej, gdyby dodawany był przyrostek -dev lub pre? Oczywiście, że by było.
A ja myślałem, że obecnie (2.6) wystarczy, że ‘y’ jest parzyste (bo 6
), a ‘zz’ może być dowolne i kernel jest stabilny 
Co do “rok.miesiąc”, to co będzie jak jakimś cudem wydadzą 2 wersje w tym samym miesiącu ? Już bardziej mi się podoba pomysł ze zwiększaniem pierwszej i środkowej liczby co jakiś czas. Tyle ze jak wyjdzie 3.1.1 to cześć osób będzie miała opory odnośnie stabilności takiego kernela przez powtarzanie mitów, że jak cyfra jest nieparzysta to niestabilny.
no i po to wlasnie, by uniknac takich nieporozumien (widac nie wszyscy wiedza o co chodzi) – ma byc nowy system. tj. ladne oznaczenie wersji stabilnej + kilka rc dla wersji niestabilnych.
A od kiedy to RC (przypominam RC – Release Candidate) ma być oznaczana wersja niestabilna oprogramowania?
Candidate, czyli kandydat na stabilny, niekoniecznie taki jest.
zazwyczaj ostatni RC staje się stabilnym
Ale też nie jest wersją rozwojową, RC jest wersją w której nie zachodzą inne zmiany niż poprawki nowo powstałych błędów czy regresji.
no i od tego beda wersje -dev
Taki jak w Ubuntu
no w ubuntu sie to sprawdzilo, wyglada estetycznie i nie odstrasza sporymi liczbami.
moze dzieki temu uda sie uciec przed ciaglymi pytaniami – kiedy 2.7? kiedy 2.8? kiedy ta rewolucja?
a także w Gentoo, Archu i pewnie paru innych
Móglbyś przynajmniej tekst jakoś przeredagować, na idg jest słowo w słowo
bo generalnie napisali to dobrze i fachowo :p
To powinno być jako cytat.
tak tez zmienilem…
jak się cytuje, to sie podaje źródło.
przeciez ponizej masz linka do orginalu…
masz pozwolenie do kopiowania tekstu?
jesli nie – zaznaczaj ze to cytat…
Może zaakceptować dwa sposoby numeracji? Jeden dla zwykłego zjadacza chleba(ten proponowany rok/miesiąc), a drugi dla dewów? Tylko, co wtedy będą z ludźmi robiły wielkie portale? Już widzę informację: kernel Linuksa na starej numeracji 2.7.1 i na nowej numeracji 2009.2 jednocześnie…..
Oczywiście, to wydania niestabilne nie byłyby oznaczana w sposób dla zwykłego człowieka. Taki chwytak na narzekaczy.
Nieeeeee! To zaproszenie do mega-bałaganu. Powinna być jedna wersja, najlepiej bez nazwy kodowej.
Jakoś Java 1.5/5 i Java 1.6/6 sobie radzą…
3.0 w 2010 roku? Linus chyba zwariował, a krenel będzie przepisany w .net.
IMHO beznadziejne jest w przypadku kernela numerowanie według roku czy miesiąca, już chyba lepiej byłoby wywalić tę dwójkę i zamiast 6 wstawić 8 od roku 2008 czy 10 od roku 2010.. Co ma wspólnego rok 2010 z cyfrą 3? Niewiele, imho więcej ma wspólnego z rokiem 3000.. Zresztą teraz jest bardzo dobrze, kernel seria 2, główna wersja 6, podwersja 24, poprawki 3. Można zrobić tak jak np. w gnome czy kde, np. 6.24.1. Prostsze do zrozumienia dla wszystkich, prawda? Jak w DE, których używamy.. 
Nie krakaj, bo jeszcze w szale .net (mono) Linusowi też odbije, i przepisze
To wspaniała wiadomość. Skończy sie piszczenie małp o tym kiedy będzie 2.7, czy inne podobne wymysły. To samo powinni zrobić w Gnome.
hmmm… dobry pomysl…
podeslij na liste dyskusyjna
taa i najlepiej niech wszyscy używaja jednakowego sposobu oznaczanai wydań to już wogolue polapiemy sie co jest co…
Dokładnie
Skoro to takie dobre numerowanie, to może będzie Linux 2008.10, KDE 2008.10, Firefox 2008.10, Bash 2008.10, itd.
A wtedy dopiero będą nooby płakać, jak będą mieli kernel 2008.10, a tu już grudzień będzie. Znaczy, że jakaś stara wersja, i pewnie ma bugi i zaraz mnie shakują. To dopiero się mity potworzą i pole do FUDu.
Wersje niezależne od dat coś mówią, a przynajmniej pozwalają zawrzeć tam jakąś informację. Daty nic i potem nie będzie odwrotu. Do tego datę wydania danej wersji zawsze można sprawdzić, a tak na prawdę mało kogo ona obchodzi.
Podobne rozwiązanie miało być w FreeBSD, ale padło by były duże poślizgi.. 7.0 miało być w 2007, a po kropce miało oznaczać kwartał..
A to jest słuszna uwaga. Pod koniec roku może się zdarzyć, że wydanie kernela 200x.4 przesunie się na początek kolejnego. I co wtedy, bałagan typu ,,2009-rc was released as 2010.1”?
Nb. pewna duża firma przeszła 13 lat temu z numeracji swoich produktów tradycyjnej, tj. 3.11 na związaną z rokiem – 95, 98, Millenium Edition, 2000
Tylko, że 98 miało był 97
Ponieważ to closed source, to mało kto o tym wie. Ale w społeczności OpenSource takie poślizgi się nie ukryją.
ja im proponuje zmienic zarzad i developerow porzadnych zatrudnic
Sorki ze tak osobiscie ale ja porpunuje o 1 nad ranem wypic wiecej kawy bo widze ze przysypiasz
Zaletą obecnego schematu MM.mm.pp jest to, że istnieją pewne zasady zmieniania tych numerów, chodzi mi przede wszystkim o numer mm – wiadomo, iż jego zmiana oznacza poważne zmiany w przynajmniej jednym podsystemie (np. wprowadzenie netfilter w 2.4 czy udev w 2.6) i jeżeli chcemy dokonać aktualizacji do tej wersji, potrzebna będzie modyfikacja oprogramowania przestrzeni użytkownika i konfiguracji systemu. W schemacie opartym tylko na datach takiej informacji będzie brakować.
Kto się zgadza? Wpisywać miasta!!!!!1
Za długi, zamiast 2008.x lepij byłoby 8.x 9.x 10.x itp liczba pochodzaca od roku.
Takie datowanie wydań niezbyt mi się podoba, lepszym pomysłem byłby powrót do gałęzi rozwojowej – 2.6.x wydanie stabilne, tam poprawiają bezpieczeństwo i łatają, nowinki do 2.7.x, a gdy już powsadzają co nowego chcieli, to leci 2.8.x-rcY, aż do uzyskania stabilności. Dalej 2.9 i w koło Macieju
Wymuszenie zmiany drugiej cyfry co rok myślę, że było by sztuczne i niepraktyczne. Numerki powinny być determinowane zmianami w kodzie.
no właśnie do tego już nie chcą wracać – 3 lata w świecie kernela to bardzo dużo…
A czasami poprawki nie są warte tego, żeby popychać ‘drugą liczbę’ – a z drugiej strony, zapowiadane usunięcie BKL (Big Kernel Lock) może być impulsem nawet do popchnięcia ‘pierwszej’ (i co, powinien być 2->3 ? Linux 3.0 ?)
Obecny model zakłada dużo szybsze ‘dołączanie’ nowych ficzerów, driverów etc. w ciągu dwutygodniowego okna, a potem około 2 miesiące na stabilizację kodu, usunięcie regresji itp.
Ja tam osobiście nie pisuję na lkml… ale mnie podobałby się schemat : s.yy.ww.tt (s- seria : tak jak dotychczas – 2, można podnieść do 3 jak np. usunie się BKL, yy – ostatnie cyfry roku, ww – numer tygodnia wydania stabilnego, tt- numer tygodnia wydania gałęzi ’stabilnej’ (akumulującej mniejsze pacze, które i tak i tak wchodzą do następnego RC, ale nie przyjmującej nowości) – wtedy, 2.6.26 (wydane całkiem niedawno) byłoby 2.8.ww, developerzy pracują nad 2.8.ww-rcX (w momencie uznania wersji za stabilną ww zmienia się w numer tygodnia w którym zostało wydane) a stable-team pracuje nad 2.8.ww.tt itd. W przyszłym roku, 8 podniesie się do 9 i tak dalej. Czyli po wydaniu np. 2.8.30 developerzy pracują nad 2.8.30-rcX, aż w końcu wydadzą powiedzmy 2.8.40, a w tym czasie stable wyprodukuje 2.8.30.[34,38,40...]
Zalety ? podobne do starego schematu, ale niesie dokładniejszą (co do tygodnia) informację o dacie, z której pochodzi dany kod (a o to zdaje się chodziło pomysłodawcy…)
(public-domain
A ja uważam że wersjonowanie oprogramowania nie powinno w żadnym wypadku zależeć od daty – bo niby czemu to ma służyć? Wersja oprogramowania ma określać wersję a nie datę kiedy została wydana bo to akurat jest najmniej ważne. Jeżeli np w kodzie nic się nie dzieje (z jakiegoś tam powodu) to dlaczego ma być podbijana wersja skoro nic się nie zmieniło (oprócz tygodnia)?
Odnoszę wrażenie że jest to szukanie “dziury w całym” bo taka zmiana niczemu nie będzie służyć a jedynie powodować ogromne zamieszanie.
No, jeśli w kodzie nic się nie zmieniło, to wersja po prostu zostaje ta sama… jak się tylko rekompiluje, to można podbić jakiś build-number np.
Kernel obecnie rozwija się dość szybko (kolejne wydania co 2-3 miesiące). To co napisałem nie psuje przy okazji obecnego schematu W.X.Y[.Z] i łatwo to zaadoptować.
Ale po co wersja ma zależeć od daty? Żeby było fajnie i inaczej niż jest teraz?
Nie…
czy ktoś wygra, czy nie, czy to ważne ?
ale kernel już nie zmienia się tak fundamentalnie, jak w czasach 2.4->2.5->2.6, gdzie bywało, że całe interfejsy się zmieniały z 2.X.Y na 2.X.Z… teraz odbywa się to dużo płynniej i szybciej i mniej ‘wstrząsowo’. A stary system numerowania wersji po prostu odstaje od stylu rozwoju, stąd, ktoś spytał, a Linus zareagował ogłoszeniem konkursu
Po to że Linux już dawno przestał być tylko dla wyjadaczy komputerowych a coraz częściej jest adoptowany przez biznes i zwykłych domowych klikaczy.
Z drugiej strony czemu tak wolno jest adoptowany? Właśnie przez słaby marketing a raczej jego brak.
Moim zdaniem jest to posunięcie w dobrym kierunku. Zwykły użytkownik nie musi wiedzieć co to jest dokładnie za wersja a jedynie, że jest jakaś tam nowa, format taki jaki proponuje idealnie to załatwia
Dla devów i guru można nadal trzymać liczbową żeby się nie pogubić.
z tą którą ja opisałem, to i dev i guru się też nie pogubią
Przy 2 wersjach to byś się dopiero pogubił.
No to ja już nic nie rozumiem w takim razie. Że niby te wersje ROK.MIESIĄC to ma być marketing? Skoro zwykły użytkownik musi wiedzieć tylko ze jest nowsza wersja to w czym przeszkadza aktualny format wersji?
Troche przesada z tym marketingiem, ale, ma to co najmniej znaczenie psychologiczne – ten drugi numerek w wersji (2._6_) zasiedział się trochę, a nawet widziałem Linusa postującego, że ta szóstka już się nigdy nie zmieni, bo już dawno, dawno (od 2.6.18 ?) przestali stosować stary system numerowania, zastępując go przez -rc i -stable. A zwykły user, to zobaczy 2.6… za parę lat i pomyśli ‘ee tam, nic się nie zmieniło…’ Stąd mój pomysł wersjonowania po tygodniach. Nie psuje starych zwyczajów, tylko je mocno zwija
aha, no i oczywiście, mój pomysł nie psuje starego formatu tak jak propozycja o 2009.1 go psuje…
Ale jest powiązany z czasem a nie powinien być, bo to nie czas kieruje rozwojem produktu a zmiany w nim. Zmiana numeru wersji powinna być podyktowana zmianami w kodzie, od wielkości i zasięgu tych zmian powinna być podbijana odpowiednia liczba.
Ale trzeba mieć zdefiniowane reguły rządzące tymi zmianami – a w obecnym stanie, zdefiniowane jest W.X.Y.Z : W=2 zmienia Linus, X=6 ma tak zostać, (Y=26, Z)=wiadomo co. Więc skoro X=6 miałoby już nigdy się nie zmienić, to właściwie, czemu się tego nie pozbyć ? Jak zdecydować, kiedy podbić X ? A tak, z moim pomysłem, robiąc release mamy to automatem i wiadomo, że 2.09.10 jest nowszy niż 2.08.30…
Data jest wazna przy podawaniu wersji bo od razu widac czy to jest stara wersja czy nowa. Wazne jest do szczegolnie dla nowych uzytkownikow, ktorym bez problemu mozna wcisnac ze 2.2.11 jest najnowsza wersja linuxa. A juz ciezko komus wcisnac ze 1997.3 jest nowa wersja.
I ciekawe po co nowemu użytkownikowi wiedza o tym, która wersja jest najnowsza
Jakoś nie widzę ZU kompilującego samemu źródła kernela, co najwyżej może go zaktualizować za pomocą managera pakietów wbudowanego w system, a w nim raczej będzie wersja dość nowa.
@bk
I kto tak wciska userom stare wersje? Znasz ludzi co aż tak im się nudzi?
A poza tym “nowy użytkownik” nie używa linux-image-2.6.26, tylko openSuse 11.0, Fedory 9, Ubuntu 2008.cośtam.bo.nawet.nie.pamiętam, albo innych dystrybucji w ich własnych wersjach. I mało go wersja kernela obchodzi. Więc nie sprowadzajmy problemu do nowych użytkowników, których sprawa w ogóle nie dotyczy.
Bo wersja zależy od daty! Rozwój kodu nastepuje w czasie, więc wiadomo, że w czasie t1 drzewo było w stanie s1, w czasie t2 w stanie s2 itd…
Numerowanie na podstawie daty (lub numerów kolejnych rewizji, a’la subversion) jest najbardziej naturalnym systemem.
@krzy
Rotfl. Twoje matematyczno-logiczne wywody są do pupy.
Wersja jest po to, aby oznaczyć ZMIANY zachodzące w kodzie, a nie datę, kiedy wypuszczono kod.
Rozumiem, że dużo ci powie jak będziesz miał KDE 2008.02 i KDE 2008.01, nie? A może więcej – odpowiadające powyższym, w tej kolejności (sic!) – KDE 3.5.9 i KDE 4.0.0?
Kontynuując przykład KDE: widzisz LOGIKĘ numeracji? Pierwsza cyfra opisuje na jakiej bibliotece Qt się opiera – jej zmiana oznacza drastyczne zmiany całego środowiska. Kolejna liczba opisuje większe zmiany. Zapewne dopuszczalne są wtedy niekompatybilności plików konfiguracyjnych, etc. A ostatnia, to drobne wydania naprawiające wykryte błędy i dodające mało znaczące funkcje.
WERSJA != DATA
W przypadku KDE pewna logika jest.
W przypadku Linuksa nie ma od dawna żadnej. Mówimy o ludziach którzy wymieniają scheduler zmieniając numerek na trzecim miejscu.
To lepiej chyba nadal zaprowadzić ten porządek numerowania a nie wymyślać jakieś sztuczne oznaczenia wersji opartych o daty, jakieś tygodnie itd. – nie wnosi to nic oprócz zamieszania.
To że rozwój zachodzi w czasie to normalne, ale wersja ma oznaczać wersję kodu a nie datę. Rzeczywiście numerowanie po numerze rewizji w VCS-ie jest dobre:
- Jaką masz wersję XYZ?
- 45345734.
Rewizja to co innego, używam SVN-a do prowadzenia projektów ale każdy ma normalny format wersji tzn. MAJOR.MINOR.PATCH i takie są używane w nazwach branch-ów (bez PATCH) i tag-ów.
Jeżeli coś takiego przejdzie to znaczy że na prawdę rozwój Linuksa schodzi na dno.
Bez sensu.
Numeracja a.b.c.d wszystko mówi.
Mnie nie mówi nic bez poczytania changelog-a. Szczególnie dziś, kiedy numer zwiększa się tylko o +=0.0.1, a zmiany są całkiem spore. Niedługo dojdziemy do takiego stanu jak w Gnome, gdzie od wersji 2.0 praktycznie 75% bibliotek się zmieniło a my dalej mamy mało mówiące 2.xx ze stadem troli żądającym 3.0 bo nie widzą zmian. Widać dziś, że tradycyjne oprogramowanie otwarte wyewoluowało z początkowo dużych zmian raz na jakiś czas do średnich i małych zmian, które z czasem przynoszą duża zmianę pomiędzy większą ilością wydań. Otwarte oprogramowanie z racji swojej poprawkowej natury stało się raczej subskrybowane jak jakieś gazety. Stąd oznaczenie wydań przez datę. Równie dobrze moglibyśmy przejść na numerowanie kolejnych wydań przez rzymską liczbę (bardziej kłopotliwe).
Dodam jeszcze ze OSS rozwija się mniej wg planów a bardziej wg pomysłów i paczy które przysyła społeczność, dlatego trudno i kłopotliwe jest dziś wydawanie nagle wiekszych releasów.
to może słowami opisywać: eksperymentalna, kandydacka, bardzo niestabilna, mało niestabilna, czasem niestabilna, nieprzewidywalnie niestabilna. No bo stabilna to nigdy niewyjdzie.
Dobrze, że twój windows jest stabilny
“Kandydacka” – bardzo ładne słowo. Do pary proponuję jeszcze dorzucić “dekadencka” – też ładne słowo.
Nie ma i nie będzie stabilnych systemów (pomijając systemy zawarte w np. Commodore gdzie są “dwie-trzy” linijki kodu).
@norbert_ramzes
Nie do końca się zgodzę.
Zarówno programowanie, jak i budowa samego komputera są ścisłe jak matematyka – i jeśli nie ma błędu w żadnej z warstw, to program może być doskonały. Pomijam problemy fizyczności świata w którym żyjemy, które mogą spowodować błędy odczytu i zapisu informacji
Co zresztą program również w pewnym stopniu musi uwzględniać.
Oczywiście dokładne sprawdzanie kodu uniemożliwiło by szybki i nadążający za potrzebami rozwój, ale to nie znaczy, że się nie da.
Dlatego należy racjonalnie dążyć do doskonałości oprogramowania godząc rozwój z dbałością o jakość. Tak dzieje się właśnie w większości projektów OpenSource.
Programy i systemy komercyjne są niestety nastawione jedynie na zysk, a nie wypracowanie dobrego produktu. Jeżeli da się sprzedać nawet nieco bardziej innowacyjny bubel, to takim bublem produkt pozostanie na zawsze. Dlatego windows jaki jest, każdy widzi.
Kolega widzę nie napisał w życiu żadnego programu. Dzięki temu ma jasny pogląd na sprawę, nie zmącony znajomością tematu. Pozazdrościć.
@krzy
Koledze widać wydaje się, że zna mnie i innych usrów lepiej od nich samych. I wie ile programów napisałem. Jasnowidz czy choroba psychiczna?
Napisałem nie jeden i wiem, że da się napisać program bez błędów.
Świadczy o tym również fakt, że błąd można poprawić gdy już się go znajdzie lub zostanie zgłoszony. Jak napisałem wcześniej, taki audyt kodu na bieżąco byłby niesamowicie niewydajny. Co nie oznacza, że można zupełnie zrezygnować z jakości.
Ale takie hello world może być doskonałe przecież
Ale tu jest mowa o systemach a nie o programach…
Może przy okazji zmiany numeracji zmieniliby logo Kernela, które wygląda paskudnie.
Chodzi o tuxa, czy kernel ma jakieś inne logo? Bo tux jest bardzo ładny.
Do zmiany to się nadaje logo windows wyglądające jak krzywe okno z kolorowymi szybami niczym w witrażu. Jest bardzo tandetnie i wieśniacko w porównaniu do pingwina czy większości logo projektów opensource.
Jak już ktoś napisał – w numeracji z datami brakuje informacji o wprowadzonych zmianach i o gałęzi. Bo jak rozpoznamy czy to 2.7.1 czy 2.8 (duże zmiany), jeśli będę miał wersje 2008.1 i 2008.2?
Fascynujące.
Zamiłowanie p. Torvaldsa do wynajdywania na nowo koła jest doprawdy godne podziwu. Gdyby tak używał np. subversion, to wystarczyłoby podać numer rewizji w stylu r12345 i… już. No, ewentualnie nawet wprowadzić identyfikatory gałęzi w stylu /branches/stable plus numer rewizji.
Ale nie. Najpierw trzeba było napisać własny system kontroli wersji (w którym identyfikatorem rewizji jest jej hasz SHA-1, żeby broń Boże nie dało się tego zapamiętać), aby teraz móc wprowadzić nowy, autorski system numeracji.
Z tą numeracją wersji, to nie wynalazł na nowo koła, tylko chyba głupieje na starość.
To, że w svn taka numeracja się sprawdza, nie oznacza, że sprawdzi się w gotowym projekcie.
Poza tym używając svn znasz dany projekt. Dla ciebie rewizja 30021 nie różni się od 30001 o 20. Ty wiesz, że np. od 29900 do 30010 to była WERSJA 2.0, a od 30011 jest już 2.1. Rozumiesz zmiany w kodzie i działaniu programu i jaki kolejny etap został zakończony.
Ciekawe co byś mógł powiedzieć na temat programu po samym numerze rewizji.
Numeracja datą ujdzie dla całych dystrybucji, które wydawane są raz czy dwa w roku, ale nie dla szybko rozwijających się projektów mających releasy co 2-4 tygodnie.
Choć jak dla mnie dystrybucje numerujące się datą pokazują, jakby liczyły czas do wydania wersji 1.0
Na prawdę – takie wrażenie odnoszę. Więc i zapewne wielu nowych userów też – i omijają je z daleka.
Ja tego nie muszę wiedzieć. Od tego są tagi i logi w repozytorium, żeby to było poopisywane.
Ciekawe co byś mógł powiedzieć na temat programu po samym numerze rewizji.
A co mogę powiedzieć na podstawie 2.6.24-19? Tylko tyle, że mam do czynienia z rewizją 24-19, bo 2.6 jest tam z powodów historycznych i już raczej zmianie nie ulegnie. Co więcej, jeśli wyjdzie nowa wersja, to informacja czy będzie się nazywać 24-20 czy 25-1 też mi niewiele powie, bo kryteria wersja/podwersja są niejasne.
Tak czy tak muszę patrzyć do changeloga, więc nie ma po co sztucznie komplikować systemu.
Skoro jest niejasność wersji kernela, to powinno to zostać wyjaśnione i w przyszłości przestrzegane.
A nie zmieniamy zapis wersji i skoro aktualny jest niejasny, to użyjmy zupełnie nic nie znaczącego (poza datą, co jest śmieszne).
Ludzie nigdy tego nie róbcie, co to za dziwna moda na podawanie wersji jako numer rewizji. Zmieni się VCS i co wtedy będzie się podawało? Wersja w repozytorium to jedno a wersja wydawana to drugie. Poza tym branches/stable-325432 też nie wiele nam mówi. Wg. mnie najdoskonalszym formatem wersji który sprawdza się w 90% przypadków jest MAJOR.MINOR.PATCH i tak np mamy branches/2.6 i tags/2.6.0, tags/2.6.1 itd. Wiele projektów korzysta z takiego formatu i ma się dobrze, nikt nie narzeka na jakieś niedogodności z tym związane tylko raz ktoś na jakiś czas musi wyskoczyć z innowacyjnym pomysłem ROK.MIESIĄĆ – ot tak dla rozrywki i mącenia.
Kto zmienił tytuł na taki z Ubuntu w treści?! Gentoo, Arch i inne też tak się oznacza nie tylko Ubuntu. Poza tym bubu ma skrócone 08.04 a nie 2008.04.
Wiem, że się czepiam ale..
nie czepiasz się – słuszna uwaga
Numerowanie YYYY.MM to numerowanie w Arch Linux i Gentoo.
Ubuntu numeruje Y.0M (miesiące z zerem wiodącym)
tytuł w takiej postaci to zwyczajna bzdura