Nein, das wurde ja auch garnicht erwähnt. Es ging darum, dass einige Nutzer 11.0 als "wichtiger" hielten, als zum Beispiel 11.3. Obwohl 11.0 genauso wie 11.3 ein "eigenständiges" Produkt ist. Sprich, jeder Release ist für sich einzigartig, und das Major-Minor-System ist nur "Design" Einige Nutzer hielten allerdings 11.3 oder 11.4 nur als Service Pack für 11.0. Da auch von einigen Medienvertretern so gehandelt wurde, dachten diese, 11.4 ist nur ein Service Pack für 11.0 und berichteten nicht darüber, weil es nicht interessant genug war.
Ich, als Mitglied im Wiki/News-team finde, das versionsnummern egal sind, bin aber froh, jetzt klarheit zu haben.
Also ich finde die neue Versionsnummer 12.1 sehr seltsam.
Dann finde ich, sollte man gleich alles mit 1, 2, 3,... durchnummerieren und fertig. Und wenn man große Änderungen doch kennzeichnen will, dann macht ein Plus dahinter: 1, 2, 3, 4+, 5, 6,... Dann sieht nix nach Servicepack oder sonst was aus.
Zu den alten Nummern: Ich persönlich habe den *.0 Versionen meist weniger Beachtung geschenkt, da früher einige 0er Versionen nicht so der Brüller waren. Die *.1 waren dann schon wesentlich besser. Ich glaube 10.0 war so ein Fehlgriff. 10.1 aber deutlich besser. In der Firma sind wir aber mittlerweile von suse ganz weg, da die maximale Unterstützung von 18 Monaten schon knapp war. Und jetzt auf 12 Monate - das da war man mit den Umstellungen fertig und konnte gleich wieder anfangen. Wir sind deswegen jetzt bei CentOS gelandet.
"da früher einige 0er Versionen nicht so der Brüller waren."
Das sind sie, die Missverständnisse. Nicht dass Du völlig unrecht hättest, aber gehen wird das doch einmal durch.
Suse 5.0: Einführung von rpm, 4.4.1 war stabiler. Schlechte Erinnerungen daran habe ich keine. Also o.k.
Suse 6.0: Glibc 2.0 statt libc 5, aber immer noch alter, erprobter Kernel 2.0. Mit KDE 1.0 lief sie ganz gut. Erst Suse 6.1 kam mit Kernel 2.2. Wie üblich bei Suse wurden Kompatibilitätspakete für alte Anwendungen mitgeliefert (u.a. shlibs5). Suse 6.0 war somit o.k.
Suse 7.0: Erprobter Kernel 2.2, "rock-solid"-KDE 1.1.x, dafür aber mit Bleeding Edge-XFree 4.0.0. Wirklich nicht so der "Brüller", auch wenn der alte XFree 3.3.6 aus Kompatibilitätsgründen natürlich mitgeliefert wurde. Nicht so ganz o.k., aber annehmbar.
Suse 8.0: Alter und erprobter gcc-2.95, alte und erprobte glibc 2.2.x, dafür die "unfertige", aber "stabile" KDE 3.0.0-Desktopumgebung. Auch das war nicht gerade der "Brüller". Allerdings wurde ruckzuck das KDE 3.0.3-Update nachgeliefert (typisch S.u.S.E./Suse, auf so etwas konnte man sich immer verlassen; das gilt bis heute, siehe u.a. die openSUSE 11.1-Updatehistorie und auch die Suse 10.1-Remastered Version samt "Apology" (kein Witz)). Also gerade noch so o.k.
Suse 9.0: Die letzte Version mit Kernel 2.4, vielen erprobten, gut ausgetesteten Versionen, XFree 4.3 mit funktionierendem "3D", ein gut gepflegter KDE 3.1.x. IMHO die beste SuSE aller Zeiten. Spitzenmäßig, "über-o.k.". Suse 9.1 kam hingegen mit einem sehr jungen Kernel 2.6 und hatte Fehler über Fehler. Darunter fällt auch das letztlich leider misslungene, desktopübergreifende submount-Experiment, das mit Suse 9.1 gestartet wurde.
Suse 10.0: Das eigentlich Neue gegenüber der sehr guten Suse 9.3 war leider, dass USB ziemlich kaputt gewesen ist. Deshalb nicht o.k. Suse 10.1 hatte seinerseits ein ziemlich defektes Paketmanagement mit zypper, rug, usw. (das Paketmanagement funktionierte in Suse 10.0 noch völlig problemlos), ein Problem, das erst mit dem Erscheinen von openSUSE 11.0 wirklich gelöst wurde.
openSUSE 11.0 war hingegen eine ordentliche Distro (rock-solid, "stabil"), das Paketmanagement funktionierte endlich wieder und auch der Notebook-Festplattenbug wurde schneller gelöst als bei Ubuntu. Also o.k.
Die Nuller-Versionierung sagt also praktisch nichts aus, eine Nuller-Version kann (fast) Mist sein, sie kann o.k. sein. Auch viel Neues muss sie nicht unbedingt enthalten. Also weg mit der Nuller-Versionierung. Das ist o.k.
Das neue System deutet nichts mehr an und sagt praktisch gar nichts aus, außer, dass innerhalb einer Serie immer eins dazu gezählt wird und man dann nach zwei Jahren auf den nächsten (n+1)-Zweijahreszyklus wechselt. Das sind nur noch Zahlen ohne wirkliche Bedeutung, letztlich nur bloße "Namen". Summa summarum verzichtet openSUSE endgültig auf die mögliche "Marketingfunktion" der x.0-Veröffentlichungen. Die so benutzten Nullen sind in Zukunft unnötig und werden hiermit abgeschafft.
Findest du? Ich finde, es deutet schon noch etwas an, den von mir beschriebenen Fall: Eine 12.1 wirkt wie eine bereits verbesserte Version von 12.0 und ist somit immer noch ein Riesensprung gegenüber 11.4. Ich verstehe einfach nicht, warum man so sehr auf dieser Nummerierung bestehen bleibt, wenn sie überhaupt nichts mit den Fortschritten zu tun hat.
Für mich wäre das vergleichbar, als wenn Canonical jetzt sagt, bei der Versionierung von ubuntu wird zukünftig für das Monat eine Zufallszahl von 0-6 Monaten hinzugezählt. Im April erscheint beispielsweise die 11.09 und im Oktober die 11.10. Damit ginge auch der Sinn der Jahr-Monat-Versionierung verloren.
Vielleicht sollte man die Versionsnummern komplett durch den Kakao zeihen, damit es auch wirklich jeder bemerkt, dass sie letztlich irrelevant sind, so wie Slackware 13.37. OpenSuse könnte z.B. noch die Versionsnummern 1.0 bis 4.1 nachholen. :-)
Ich finde die ganze Nummerierung ohnehin fragwürdig und diese Lösung scheint mir mehr wie eine Verdrängung des Problems ist (also das Missverständnis über den technischen Fortschritt der Distribution ist). Es hat einen Grund, warum Leute beim Sprung von 10.4 zu 11.0 glauben, dass sich mehr getan hat. Wozu werden die Versionen so "komisch" benannt, wenn der Unterschied zwischen ihnen überhaupt nichts damit zu tun hat?
Abgesehen davon sieht es immer noch so aus, als wenn 12.1 gegenüber 11.4 mehr Neues bietet als 11.3 zu 11.4 - es lässt sogar den Eindruck erwecken, dass es bereits stabiler ist als ein 12.0 ...
Von Idiotenpfleger am Sa, 9. April 2011 um 23:59 #
Zitat: "es lässt sogar den Eindruck erwecken, dass es bereits stabiler ist als ein 12.0 ..."
ein 12.0, dass es niemals gab...
Ich finde die neue Nummerierung im Gegenteil sehr sinnvoll, da sie endlich einen Sinn ergibt. Mir erschließt sich nicht, wie man darauf kommen kann, dass 12.0 besser und stabiler als 11.4 sein muss. Genau wie, dass 12.1 stabiler ist als 12.0...
Bei Ubuntu gibt es ebenfalls dieses Schema "Jahr und Monat des Erscheinens der Version". Das ist sinnvoll, denn so ist die gesamte Nummerierung losgelöst von dem Denken "höher = stabiler". Nein! Höhere Nummer = neuer, aktueller!
Wenn es so wäre, dass jeder Benutzer denkt "hohe Nummer = viel besser", dann müssten ja all die Windows-Fanboys im Dreieck springen, weil es nun "7" heißt und nicht mehr "95", was ja nach diesem Denkschema fast schon überirdisch sein müsste. Oder? und dann denke man mal an "2000"...
Ich habe noch nie davon gehört, dass ein Nutzer auf 11.0 umgestiegen wären weil die Nummer "0" so wichtig ausschaut...
Egal: Sollen Sie halt nummerieren wie sei es für richtig halten
Slackware ist sowieso schon "weiter", bald bei Version 13.37. :-)
Nein, das wurde ja auch garnicht erwähnt. Es ging darum, dass einige Nutzer 11.0 als "wichtiger" hielten, als zum Beispiel 11.3. Obwohl 11.0 genauso wie 11.3 ein "eigenständiges" Produkt ist. Sprich, jeder Release ist für sich einzigartig, und das Major-Minor-System ist nur "Design" Einige Nutzer hielten allerdings 11.3 oder 11.4 nur als Service Pack für 11.0. Da auch von einigen Medienvertretern so gehandelt wurde, dachten diese, 11.4 ist nur ein Service Pack für 11.0 und berichteten nicht darüber, weil es nicht interessant genug war.
Ich, als Mitglied im Wiki/News-team finde, das versionsnummern egal sind, bin aber froh, jetzt klarheit zu haben.
Also ich finde die neue Versionsnummer 12.1 sehr seltsam.
Dann finde ich, sollte man gleich alles mit 1, 2, 3,... durchnummerieren und fertig. Und wenn man große Änderungen doch kennzeichnen will, dann macht ein Plus dahinter: 1, 2, 3, 4+, 5, 6,... Dann sieht nix nach Servicepack oder sonst was aus.
Zu den alten Nummern: Ich persönlich habe den *.0 Versionen meist weniger Beachtung geschenkt, da früher einige 0er Versionen nicht so der Brüller waren. Die *.1 waren dann schon wesentlich besser. Ich glaube 10.0 war so ein Fehlgriff. 10.1 aber deutlich besser. In der Firma sind wir aber mittlerweile von suse ganz weg, da die maximale Unterstützung von 18 Monaten schon knapp war. Und jetzt auf 12 Monate - das da war man mit den Umstellungen fertig und konnte gleich wieder anfangen. Wir sind deswegen jetzt bei CentOS gelandet.
"da früher einige 0er Versionen nicht so der Brüller waren."
Das sind sie, die Missverständnisse.
Nicht dass Du völlig unrecht hättest, aber gehen wird das doch einmal durch.
Suse 5.0: Einführung von rpm, 4.4.1 war stabiler.
Schlechte Erinnerungen daran habe ich keine.
Also o.k.
Suse 6.0: Glibc 2.0 statt libc 5, aber immer noch alter, erprobter Kernel 2.0. Mit KDE 1.0 lief sie ganz gut. Erst Suse 6.1 kam mit Kernel 2.2. Wie üblich bei Suse wurden Kompatibilitätspakete für alte Anwendungen mitgeliefert (u.a. shlibs5).
Suse 6.0 war somit o.k.
Suse 7.0: Erprobter Kernel 2.2, "rock-solid"-KDE 1.1.x, dafür aber mit Bleeding Edge-XFree 4.0.0. Wirklich nicht so der "Brüller", auch wenn der alte XFree 3.3.6 aus Kompatibilitätsgründen natürlich mitgeliefert wurde.
Nicht so ganz o.k., aber annehmbar.
Suse 8.0: Alter und erprobter gcc-2.95, alte und erprobte glibc 2.2.x, dafür die "unfertige", aber "stabile" KDE 3.0.0-Desktopumgebung. Auch das war nicht gerade der "Brüller".
Allerdings wurde ruckzuck das KDE 3.0.3-Update nachgeliefert (typisch S.u.S.E./Suse, auf so etwas konnte man sich immer verlassen; das gilt bis heute, siehe u.a. die openSUSE 11.1-Updatehistorie und auch die Suse 10.1-Remastered Version samt "Apology" (kein Witz)).
Also gerade noch so o.k.
Suse 9.0: Die letzte Version mit Kernel 2.4, vielen erprobten, gut ausgetesteten Versionen, XFree 4.3 mit funktionierendem "3D", ein gut gepflegter KDE 3.1.x.
IMHO die beste SuSE aller Zeiten.
Spitzenmäßig, "über-o.k.".
Suse 9.1 kam hingegen mit einem sehr jungen Kernel 2.6 und hatte Fehler über Fehler.
Darunter fällt auch das letztlich leider misslungene, desktopübergreifende submount-Experiment, das mit Suse 9.1 gestartet wurde.
Suse 10.0: Das eigentlich Neue gegenüber der sehr guten Suse 9.3 war leider, dass USB ziemlich kaputt gewesen ist.
Deshalb nicht o.k.
Suse 10.1 hatte seinerseits ein ziemlich defektes Paketmanagement mit zypper, rug, usw. (das Paketmanagement funktionierte in Suse 10.0 noch völlig problemlos), ein Problem, das erst mit dem Erscheinen von openSUSE 11.0 wirklich gelöst wurde.
openSUSE 11.0 war hingegen eine ordentliche Distro (rock-solid, "stabil"), das Paketmanagement funktionierte endlich wieder und auch der Notebook-Festplattenbug wurde schneller gelöst als bei Ubuntu.
Also o.k.
Die Nuller-Versionierung sagt also praktisch nichts aus, eine Nuller-Version kann (fast) Mist sein, sie kann o.k. sein. Auch viel Neues muss sie nicht unbedingt enthalten.
Also weg mit der Nuller-Versionierung.
Das ist o.k.
Das neue System sagt aber genauso wenig aus ...
Das neue System deutet nichts mehr an und sagt praktisch gar nichts aus, außer, dass innerhalb einer Serie immer eins dazu gezählt wird und man dann nach zwei Jahren auf den nächsten (n+1)-Zweijahreszyklus wechselt.
Das sind nur noch Zahlen ohne wirkliche Bedeutung, letztlich nur bloße "Namen".
Summa summarum verzichtet openSUSE endgültig auf die mögliche "Marketingfunktion" der x.0-Veröffentlichungen.
Die so benutzten Nullen sind in Zukunft unnötig und werden hiermit abgeschafft.
Findest du? Ich finde, es deutet schon noch etwas an, den von mir beschriebenen Fall: Eine 12.1 wirkt wie eine bereits verbesserte Version von 12.0 und ist somit immer noch ein Riesensprung gegenüber 11.4. Ich verstehe einfach nicht, warum man so sehr auf dieser Nummerierung bestehen bleibt, wenn sie überhaupt nichts mit den Fortschritten zu tun hat.
Für mich wäre das vergleichbar, als wenn Canonical jetzt sagt, bei der Versionierung von ubuntu wird zukünftig für das Monat eine Zufallszahl von 0-6 Monaten hinzugezählt. Im April erscheint beispielsweise die 11.09 und im Oktober die 11.10. Damit ginge auch der Sinn der Jahr-Monat-Versionierung verloren.
Vielleicht sollte man die Versionsnummern komplett durch den Kakao zeihen, damit es auch wirklich jeder bemerkt, dass sie letztlich irrelevant sind, so wie Slackware 13.37.
OpenSuse könnte z.B. noch die Versionsnummern 1.0 bis 4.1 nachholen. :-)
Ich finde die ganze Nummerierung ohnehin fragwürdig und diese Lösung scheint mir mehr wie eine Verdrängung des Problems ist (also das Missverständnis über den technischen Fortschritt der Distribution ist). Es hat einen Grund, warum Leute beim Sprung von 10.4 zu 11.0 glauben, dass sich mehr getan hat. Wozu werden die Versionen so "komisch" benannt, wenn der Unterschied zwischen ihnen überhaupt nichts damit zu tun hat?
Abgesehen davon sieht es immer noch so aus, als wenn 12.1 gegenüber 11.4 mehr Neues bietet als 11.3 zu 11.4 - es lässt sogar den Eindruck erwecken, dass es bereits stabiler ist als ein 12.0 ...
Zitat: "es lässt sogar den Eindruck erwecken, dass es bereits stabiler ist als ein 12.0 ..."
ein 12.0, dass es niemals gab...
Ich finde die neue Nummerierung im Gegenteil sehr sinnvoll, da sie endlich einen Sinn ergibt. Mir erschließt sich nicht, wie man darauf kommen kann, dass 12.0 besser und stabiler als 11.4 sein muss. Genau wie, dass 12.1 stabiler ist als 12.0...
Bei Ubuntu gibt es ebenfalls dieses Schema "Jahr und Monat des Erscheinens der Version". Das ist sinnvoll, denn so ist die gesamte Nummerierung losgelöst von dem Denken "höher = stabiler". Nein! Höhere Nummer = neuer, aktueller!
Wenn es so wäre, dass jeder Benutzer denkt "hohe Nummer = viel besser", dann müssten ja all die Windows-Fanboys im Dreieck springen, weil es nun "7" heißt und nicht mehr "95", was ja nach diesem Denkschema fast schon überirdisch sein müsste. Oder? und dann denke man mal an "2000"...
Von allen Varianten Distributions-Releases zu nummerieren, ist das die mit Abstand Dämlichste...