Das interessiert mich, als Entwickler. Was genau ist denn dein Problem mit den Versionsnummern?
Theoretisch kann es dir als reiner Anwender doch egal sein, was da für eine Nummer dransteht oder wie deren Format aussieht. Worin besteht denn deine Aufgabe und welche Vor- oder Nachteile erleidest du darin, wenn ein fremdes Softwareprodukt in einer bestimmten Form versioniert wird?
Wie ergeben sich diese 2-3 jährigen Releasezyklen, die du für die Versionierung als ausreichend anführst? Wie kommst du darauf, dass es nicht gerechtfertigt ist, Sicherheitsupdates im Rahmen eines Releases in die Versionierung mit einzubeziehen?
Grundsätzlich wird davon ausgegangen, das eine neue Hauptversion "Neue Funktionen" besitzt. Das mag aus Entwicklersicht falsch sein/keinen Sinn machen, aber das wird grundsätzlich von den Anwendern erwartet. Ein sicherheitsfix ist keine Neue Funktion. Deine Kunden erwarten eine neue Funktion! Wenn du deine Versionsnummer hochschraubst, und keine neue Funktion hinzugefügt wurde , dann könnte man das als "Verpackungsschwindel" ansehen, da die Verpakung etwas verspricht, was du nicht einhälst.
Für diesen Umstand kannst du dich bei deinen Freunden beim Marketing bedanken, denn die Versionsnummern werden viel zu häufig für Marketingszwecken missbraucht (siehe Version 10). Sie erst haben in den Benutzern die Erwartung geweckt das eine neue Hauptversion neue Funtionen bringt. Übringens ist das schnelle Hochzählen der Versionsnummern auch nichts anderes als eben ein marketinggag, den damit sagst du "Bei uns gibts halt andauernd was neues" . Oder welchen spezifischen Vorteil hat das schnelle Hochzählen denn für dich als entwickler?
Darüber hinaus erwarten benutzer auch von Editionen innerhalb derselben Hauptversion eine gewisse Kompatibilität (wurde oben schon angedeutet). Das bedeutet dass ich meine Plugins/Erweiterungen/Brachenspezifische Lösung NICHT anpassen muss, solange keine neue Hauptversion kommt (gleiches API Level).
Bei Minor Updates erwarte ich einen Knopfdruck update und gut ist. Bei Major Updates, erwarte ich dass ich eventuell meine Daten migrieren muss, APIs anpassen und nochmal nachprogrammieren muss, weil sich was geändert hat. Dies kann ich aber nicht viel häufiger alls alle 2-3 Jahre machen. Daher das Problem von FF im Buisness (im Gegensatz zum IE)
An welcher Stelle betreibt Mozilla denn mit den Versionsnummern Marketing? Wenn ich auf die Homepage gehe wird dort mit keiner Silbe von der Versionsnummber gesprochen. [1] Und auch wenn ich Firefox installiere und das erste mal Starte oder im Alltag benutze wird keine Versionsnummer angezeigt, geschweige denn damit irgendeine Fortschritlichkeit suggeriert. Erst wenn man in Help -> About Firefox nachschaut erfährt man welche Versionsnummer genutzt wird.
Firefox verwendet diese Versionierung einzig und allein aufgrund des Entwicklungsmodells. Dieses Modell hat wie jedes andere Vorteile (deshalb wird es auch u.A. vom Linux Kernel, Chromium, GNOME, KDE Frameworks, KDE SC, usw. verwendet) und Nachteile. Wenn du damit ein Problem hast gibt es die ESR Version. Man ist jedenfalls nicht grundlos auf dieses Modell umgestiegen, ich habe nämlich keine Lust wieder mehrere Jahren auf triviale funktionale Erweiterungen zu warten nur weil irgendein größeres Feature noch nicht fertig ist.
[1] https://www.mozilla.org/de/firefox/desktop/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Jun 2015 um 15:05.
Offenbar gibt es unterschiedliche Auffassungen davon, was ein beliebiger Entwickler oder ein Anwender als Funktion oder Feature betrachten würden. Das ist unbestreitbar und lass dir versichert sein, das gibt es überall mal. Darüber werden dann bei kommerziellen Produkten auch Verträge gemacht. In Bezug auf einen kostenlosen Browser bei der Versionierung von "Verpackungsschwindel" zu sprechen, finde ich etwas dreist, auch wenn es in Anführungszeichen geschrieben steht. Eventuell hilft es ja weiter, den entsprechenden Kunden freundlich auf den Lizenztext zu verweisen?
Das Marketing gibt nicht die internen Versionsnummern der Softwareentwicklung vor. Wäre ja auch schlimm. Wenn man nach außen eine andere Version kommunizieren möchte, dann wird das aber durchaus getan. Bei Mozilla hat man sich dagegen entschieden. Aus Transparenzgründen oder womöglich weil das einfach zusätzlichen Aufwand bedeutet - wer weiß?
Allgemein möchte ich als Entwickler an der Versionsnummer erkennen können, wie weit zwei Veröffentlichungen in Bezug auf die erfolgten Änderungen voneinander entfernt sind. Ob das Hochzählen für ein Produkt nun besonders schnell oder langsam zu erfolgen hat, ist nirgendwo festgeschrieben. Das hängt von den konkreten, internen Umständen ab, z.B. dem Entwicklungsmodell, der Teamgröße, wie schnell die Entwicklung voranschreitet, der Anzahl paralell gepflegter Entwicklungszweige, etc. Eine heute weitgehend beachtete Empfehlung stammt von Eric S. Raymond und lautet z.B. "Veröffentliche früh, veröffentliche oft"[1].
Vor dem Hintergrund kann ich die geforderten 2-3 Jahre Releasezyklus, ohne die Chance zwischendurch zu patchen, nicht vorbehaltlos nachvollziehen. Teure Individualsoftware, beispielsweise, würde ich persönlich nicht auf einer Plattform entwickeln, wenn ich diese nicht über den vereinbarten Zeitrum zweifelsfrei supporten kann. Wenn ich das wider besseren Wissens doch tue, dann ist das unternehmerisches Risiko.
Ich denke man kann durchaus von einem Verpackungsschwindel reden, den Firefox ist keinesweg umsonst. Ich bezahle einfach mit meinen Daten statt mit meinem Portemonai, aber bezahlen tu ich trozdem. Das Mozilla auf einen - nicht gerade kleinen - Cash Flow angewiesen ist, wurde dieser Monate zur genüge in aller öffentlichkeit breitgeschlagen.
Ausserdem wende ich mich weder gegen ein Veröffentlichungs noch gegen ein Entwicklungsmodell. Oft zu veröffentlichen ist durchaus gut, Cyanogenmod (um ein anderes Beispiel zu bringen) veröffentlicht täglich, und sie sind trozdem noch nicht bei Version Eine Plutoniarde. Auch bei Linux Kernel (Version 4) und Gnome (sogar erst Version 3) (deine eigenen Beispiel) sterben offensichtlich NICHT daran, eine Versionsnummer >10 zu haben. Nur Browser brauchen offensichtlich eine Versionsnummer im 100 stelligen Bereich.
Nochmal, wie kann hier ein Verpackungsschwindel stattfinden, wenn auf der Verpackung und auch sonst nirgends mit der Versionsnummer geworben wird?
Und deine Argumentation über der Sinnhaftikgeit der Versionsnummern ist schwachsinnig. Welche zusätzlichen Informationen liefert dir die aktuelle Kernel Version 4.1 im Vergleich zu Firefox 38.0? Kernel 4.0 hat sich in keinster Weise von 3.9 oder jetzt 4.1 unterschieden, es war ein genauso unbedeutender Release, rein technisch betrachtet sogar wesentlich langweiliger als z.B. 4.1, bei dem man nur aus Lust und Laune die Major-Nummer hochgezählt hat.
Eine Versionsnummer muss immer im Hinblick auf das Entwicklungsmodell betrachtet werden und hier ist die Versionsierung von Firefox genauso sinnvoll oder sinnlos wie die von GNOME, Linux, Chromium, Ubuntu, Fedora, texlive, TeX, systemd, kmod, usw.
Hast du also einfach nur Angst vor großen Zahlen oder was ist dein Problem? Denn dann kann man ja auch die Versionierung mit Jahreszahl und Monat etc. ausschließen. Welche überlege Versionierung schlägst du also für Time-based-Releases vor?
Herzlichen Dank, dass du daran gedacht hast. Hilft dir das weiter? So wie der Seitenhieb auf meine Freunde vom Marketing, weiter oben?
Cyanogenmod (um ein anderes Beispiel zu bringen) veröffentlicht täglich, und sie sind trozdem noch nicht bei Version Eine Plutoniarde. Auch bei Linux Kernel (Version 4) und Gnome (sogar erst Version 3) (deine eigenen Beispiel) sterben offensichtlich NICHT daran, eine Versionsnummer >10 zu haben.
Du meinst < 10. Was hat das mit dem Webbrowser zu tun? Das sind andere Projekte. Klar geht Versionierung auch ganz anders. Um es krass zu formulieren: Du kannst an dein Produkt auch einen Timestamp dranschreiben und sagen, dass dir das völlig ausreicht. Für die Entwickler von Mozilla Firefox oder Google Chrome tat es das offenbar nicht und ich kann das dank Erfahrung nachvollziehen.
Nur Browser brauchen offensichtlich eine Versionsnummer im 100 stelligen Bereich.
Selbst wenn das wahr wäre: Was ist denn jetzt noch das Problem? - unterschiedliche Erwartungen beim Nutzer - sind unbegründet, kann man ausräumen, ggf. die Lizenz lesen und im Zweifel Rechtsberatung einholen - Probleme bei der Wartung und Pflege vorhandener Anwendungen, evtl. mangelhaftes Design, Shit happens - evtl. auf Firefox ESR umsteigen (verschafft ein wenig Zeit) bzw. einen Wechsel der Plattform in Betracht ziehen
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 16:17.
Von Patrick Dreier am Do, 21. November 2019 um 20:55 #
Nein zu Umstieg auf Mozilla Firefox ESR. PaleMoon ist besser aber noch nicht ideal. Ausführen Speichern Unter Button fehlt. Adobe Flash Player funktioniert in PaleMoon, Opera 12.16,..... Mozilla Firefox hat das gleiche Problem wie der neue Opera 62 auf Info kommen die Updates. PaleMoon hat die bessere Verwaltung.
Er ist nicht schlecht soweit, sogar ganz gut und schnell. Nur zeigt er nicht alle Animationen z.b. Wetteradar an.Hat er nicht alle Plugins wie der Firefox an Bord oder woran kann dies liegen?
Das interessiert mich, als Entwickler. Was genau ist denn dein Problem mit den Versionsnummern?
Theoretisch kann es dir als reiner Anwender doch egal sein, was da für eine Nummer dransteht oder wie deren Format aussieht. Worin besteht denn deine Aufgabe und welche Vor- oder Nachteile erleidest du darin, wenn ein fremdes Softwareprodukt in einer bestimmten Form versioniert wird?
Wie ergeben sich diese 2-3 jährigen Releasezyklen, die du für die Versionierung als ausreichend anführst? Wie kommst du darauf, dass es nicht gerechtfertigt ist, Sicherheitsupdates im Rahmen eines Releases in die Versionierung mit einzubeziehen?
Grundsätzlich wird davon ausgegangen, das eine neue Hauptversion "Neue Funktionen" besitzt. Das mag aus Entwicklersicht falsch sein/keinen Sinn machen, aber das wird grundsätzlich von den Anwendern erwartet. Ein sicherheitsfix ist keine Neue Funktion. Deine Kunden erwarten eine neue Funktion! Wenn du deine Versionsnummer hochschraubst, und keine neue Funktion hinzugefügt wurde , dann könnte man das als "Verpackungsschwindel" ansehen, da die Verpakung etwas verspricht, was du nicht einhälst.
Für diesen Umstand kannst du dich bei deinen Freunden beim Marketing bedanken, denn die Versionsnummern werden viel zu häufig für Marketingszwecken missbraucht (siehe Version 10). Sie erst haben in den Benutzern die Erwartung geweckt das eine neue Hauptversion neue Funtionen bringt. Übringens ist das schnelle Hochzählen der Versionsnummern auch nichts anderes als eben ein marketinggag, den damit sagst du "Bei uns gibts halt andauernd was neues" . Oder welchen spezifischen Vorteil hat das schnelle Hochzählen denn für dich als entwickler?
Darüber hinaus erwarten benutzer auch von Editionen innerhalb derselben Hauptversion eine gewisse Kompatibilität (wurde oben schon angedeutet). Das bedeutet dass ich meine Plugins/Erweiterungen/Brachenspezifische Lösung NICHT anpassen muss, solange keine neue Hauptversion kommt (gleiches API Level).
Bei Minor Updates erwarte ich einen Knopfdruck update und gut ist.
Bei Major Updates, erwarte ich dass ich eventuell meine Daten migrieren muss, APIs anpassen und nochmal nachprogrammieren muss, weil sich was geändert hat. Dies kann ich aber nicht viel häufiger alls alle 2-3 Jahre machen. Daher das Problem von FF im Buisness (im Gegensatz zum IE)
An welcher Stelle betreibt Mozilla denn mit den Versionsnummern Marketing? Wenn ich auf die Homepage gehe wird dort mit keiner Silbe von der Versionsnummber gesprochen. [1] Und auch wenn ich Firefox installiere und das erste mal Starte oder im Alltag benutze wird keine Versionsnummer angezeigt, geschweige denn damit irgendeine Fortschritlichkeit suggeriert. Erst wenn man in Help -> About Firefox nachschaut erfährt man welche Versionsnummer genutzt wird.
Firefox verwendet diese Versionierung einzig und allein aufgrund des Entwicklungsmodells. Dieses Modell hat wie jedes andere Vorteile (deshalb wird es auch u.A. vom Linux Kernel, Chromium, GNOME, KDE Frameworks, KDE SC, usw. verwendet) und Nachteile. Wenn du damit ein Problem hast gibt es die ESR Version. Man ist jedenfalls nicht grundlos auf dieses Modell umgestiegen, ich habe nämlich keine Lust wieder mehrere Jahren auf triviale funktionale Erweiterungen zu warten nur weil irgendein größeres Feature noch nicht fertig ist.
[1] https://www.mozilla.org/de/firefox/desktop/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Jun 2015 um 15:05.Offenbar gibt es unterschiedliche Auffassungen davon, was ein beliebiger Entwickler oder ein Anwender als Funktion oder Feature betrachten würden. Das ist unbestreitbar und lass dir versichert sein, das gibt es überall mal. Darüber werden dann bei kommerziellen Produkten auch Verträge gemacht. In Bezug auf einen kostenlosen Browser bei der Versionierung von "Verpackungsschwindel" zu sprechen, finde ich etwas dreist, auch wenn es in Anführungszeichen geschrieben steht. Eventuell hilft es ja weiter, den entsprechenden Kunden freundlich auf den Lizenztext zu verweisen?
Das Marketing gibt nicht die internen Versionsnummern der Softwareentwicklung vor. Wäre ja auch schlimm. Wenn man nach außen eine andere Version kommunizieren möchte, dann wird das aber durchaus getan. Bei Mozilla hat man sich dagegen entschieden. Aus Transparenzgründen oder womöglich weil das einfach zusätzlichen Aufwand bedeutet - wer weiß?
Allgemein möchte ich als Entwickler an der Versionsnummer erkennen können, wie weit zwei Veröffentlichungen in Bezug auf die erfolgten Änderungen voneinander entfernt sind. Ob das Hochzählen für ein Produkt nun besonders schnell oder langsam zu erfolgen hat, ist nirgendwo festgeschrieben. Das hängt von den konkreten, internen Umständen ab, z.B. dem Entwicklungsmodell, der Teamgröße, wie schnell die Entwicklung voranschreitet, der Anzahl paralell gepflegter Entwicklungszweige, etc. Eine heute weitgehend beachtete Empfehlung stammt von Eric S. Raymond und lautet z.B. "Veröffentliche früh, veröffentliche oft"[1].
Vor dem Hintergrund kann ich die geforderten 2-3 Jahre Releasezyklus, ohne die Chance zwischendurch zu patchen, nicht vorbehaltlos nachvollziehen. Teure Individualsoftware, beispielsweise, würde ich persönlich nicht auf einer Plattform entwickeln, wenn ich diese nicht über den vereinbarten Zeitrum zweifelsfrei supporten kann. Wenn ich das wider besseren Wissens doch tue, dann ist das unternehmerisches Risiko.
[1] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html
Ich denke man kann durchaus von einem Verpackungsschwindel reden, den Firefox ist keinesweg umsonst. Ich bezahle einfach mit meinen Daten statt mit meinem Portemonai, aber bezahlen tu ich trozdem. Das Mozilla auf einen - nicht gerade kleinen - Cash Flow angewiesen ist, wurde dieser Monate zur genüge in aller öffentlichkeit breitgeschlagen.
Ausserdem wende ich mich weder gegen ein Veröffentlichungs noch gegen ein Entwicklungsmodell. Oft zu veröffentlichen ist durchaus gut, Cyanogenmod (um ein anderes Beispiel zu bringen) veröffentlicht täglich, und sie sind trozdem noch nicht bei Version Eine Plutoniarde. Auch bei Linux Kernel (Version 4) und Gnome (sogar erst Version 3) (deine eigenen Beispiel) sterben offensichtlich NICHT daran, eine Versionsnummer >10 zu haben. Nur Browser brauchen offensichtlich eine Versionsnummer im 100 stelligen Bereich.
Nochmal, wie kann hier ein Verpackungsschwindel stattfinden, wenn auf der Verpackung und auch sonst nirgends mit der Versionsnummer geworben wird?
Und deine Argumentation über der Sinnhaftikgeit der Versionsnummern ist schwachsinnig. Welche zusätzlichen Informationen liefert dir die aktuelle Kernel Version 4.1 im Vergleich zu Firefox 38.0? Kernel 4.0 hat sich in keinster Weise von 3.9 oder jetzt 4.1 unterschieden, es war ein genauso unbedeutender Release, rein technisch betrachtet sogar wesentlich langweiliger als z.B. 4.1, bei dem man nur aus Lust und Laune die Major-Nummer hochgezählt hat.
Eine Versionsnummer muss immer im Hinblick auf das Entwicklungsmodell betrachtet werden und hier ist die Versionsierung von Firefox genauso sinnvoll oder sinnlos wie die von GNOME, Linux, Chromium, Ubuntu, Fedora, texlive, TeX, systemd, kmod, usw.
Hast du also einfach nur Angst vor großen Zahlen oder was ist dein Problem? Denn dann kann man ja auch die Versionierung mit Jahreszahl und Monat etc. ausschließen. Welche überlege Versionierung schlägst du also für Time-based-Releases vor?
Herzlichen Dank, dass du daran gedacht hast. Hilft dir das weiter? So wie der Seitenhieb auf meine Freunde vom Marketing, weiter oben?
Du meinst < 10. Was hat das mit dem Webbrowser zu tun? Das sind andere Projekte. Klar geht Versionierung auch ganz anders. Um es krass zu formulieren: Du kannst an dein Produkt auch einen Timestamp dranschreiben und sagen, dass dir das völlig ausreicht. Für die Entwickler von Mozilla Firefox oder Google Chrome tat es das offenbar nicht und ich kann das dank Erfahrung nachvollziehen.
Selbst wenn das wahr wäre: Was ist denn jetzt noch das Problem?
- evtl. auf Firefox ESR umsteigen (verschafft ein wenig Zeit) bzw. einen Wechsel der Plattform in Betracht ziehen
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 16:17.- unterschiedliche Erwartungen beim Nutzer - sind unbegründet, kann man ausräumen, ggf. die Lizenz lesen und im Zweifel Rechtsberatung einholen
- Probleme bei der Wartung und Pflege vorhandener Anwendungen, evtl. mangelhaftes Design, Shit happens
Nein zu Umstieg auf Mozilla Firefox ESR.
PaleMoon ist besser aber noch nicht ideal.
Ausführen Speichern Unter Button fehlt.
Adobe Flash Player funktioniert in PaleMoon, Opera 12.16,.....
Mozilla Firefox hat das gleiche Problem wie der neue Opera 62 auf Info kommen die Updates. PaleMoon hat die bessere Verwaltung.
Mit freundlichen Grüssen!
Er ist nicht schlecht soweit, sogar ganz
gut und schnell. Nur zeigt er nicht alle Animationen z.b. Wetteradar an.Hat er nicht alle Plugins wie der Firefox an Bord
oder woran kann dies liegen?