Kompatibilität vs. Feature in neuen Sprachversionen

[Micke]

Verfolgt man die Pläne der Teams welche Sprachen weiterentwickeln, nennen diese als eine Bremse von neuer Funktionalität oftmals die Wahrung der Kompatibilität zu vorherigen Versionen. siehe auch "breaking changes".
Das heißt die Annahme ist, daß Konsumenten die Kompatibilität gegenüber Neuerungen vorziehen. Mich überrascht es jedesmal das zu hören, deswegen dieser Realitätscheck.

Das Kritische an einem "breaking change" ist m.M.n. nicht der Umstiegsaufwand auf die neue Version, weil man auch mit der bisherigen weiterarbeiten kann. Sondern der Umstand, dass die Sprache offensichtlich in einer problematischen Sackgasse gelandet ist, aus der sie sich nicht anderes befreien kann. Und in Folge auch der eigene Code.

Danke schonmal für die Teilnahme.

 

[Marco01_809]

Breaking changes verursachen Arbeit und damit Kosten. Allg. Planungsunsicherheit bei Updates.

Demgegenüber steht dass ich Zugriff auf irgendwelche Features bekomme die ich erstmal gar nicht zwingend brauche (mein Programm funktioniert ja schon!) und kurzfristig will ich auch gar nicht alle meine Projekte umschreiben um neues Feature XY zu verwenden (-> Regressions). Ich will auch nicht ohne Grund auf eine höhere Mindestversion springen weil mich das im Deployment einschränkt bzw. ich dann ggf. auch meine Systeme häufiger Updaten muss (-> steigert Ausfallrisiko, kostet noch mehr Zeit).

Bei einer populären Sprache oder Bibliothek sind tausende von Projekten von einem BC break betroffen. Rechtfertigt die Änderung diese Kosten bzw. kann Feature XY diese verlorene Zeit in den nächsten Jahren auch wieder einsparen? Mit Folgekosten (Ausfälle, Regressions) reden wir vielleicht von zehntausenden Stunden Arbeitszeit. Und jeder BC break birgt die Gefahr dass die Entwickler nicht bereit sind die Kosten zu tragen oder einfach nicht die Zeit haben und für Ewigkeiten auf einer alten Version mit Sicherheitslücken bleiben.
Es ist also fast immer vorzuziehen eine potentielle Neuerung solange abzumildern bzw. zu bearbeiten bis diese mit bestehendem Code kompatibel ist. Auch wenn die Endlösung dann ein bisschen weniger elegant ist oder den Entwicklern der Sprache zusätzliche Arbeit verursacht.

Bei einer Neuentwicklung oder wenn größere Umbauten anstehen nehme ich neue Features gerne mit bzw. wechsle auf modernere Schnittstellen. Aber das passiert eben nach Bedarf, nicht nach Schedule der Sprache.

 

[andy_m4]

Funktionalität

Apropos Funktionalität und Features. Aus meiner Sicht sollte es bei einer Sprache auch gar nicht darum gehen, das man viele Features hat. Weil das führt nur zu Verwirrungen. Besser man hat weniger die sinnvoll einander ergänzen und auch einfach zu benutzen sind. Bei einer gut designten Sprache gibts auch viel weniger die Notwendigkeit für "breaking changes".

Allerdings ist in der Praxis oftmals ist ja auch gar nicht unbedingt die Sprache selbst ein Problem, sondern Bibliotheken.

 

[TomH22]

Ich kann @Marco01_809 nur zu 100% zustimmen.

Ausserdem ist der Startbeitrag ohne konkretes Beispiel auch nicht besonders nützlich.

Sondern der Umstand, dass die Sprache offensichtlich in einer problematischen Sackgasse gelandet ist, aus der sie sich nicht anderes befreien kann.

Hast Du ein Beispiel wo eine Sprache in einer "problematischen Sackgasse" ist, die nur durch ein Redesign zu lösen ist?

Was ist in Deiner Definition überhaupt ein Breaking Change?
Streng genommen kann schon die Einführung eines neuen Keywords (z.B. "async" und "await") ein breaking change sein, weil es in existierendem Code Bezeichner mit genau diesem Namen geben kann. Andererseits werden diese Konflikte selten sein und lassen sich relativ leicht beseitigen. Ändert man aber z.B. die Semantik von Datentypen (so geschehen z.B. in Lua wo der Typ "Number" seit Lua 5.3 zwischen Integer und Double "Subtypen" unterscheidet) kann das erhebliche Seiteneffekte haben, die auch nicht immer offensichtlich in existierendem Code zu finden sind.

Für mich ist das abschreckende Beispiel von Breaking Changes immer noch der Wechsel von Python 2.x auf Python 3.x. Python ist eine Sprache deren Wert vor allem im großen Ecosystem an Libraries liegt, und der Übergang von Python 2.x nach 3.x hat in fast jedem Python Projekt über viele Jahre für erheblichen Mehraufwand geführt, und der Übergang ist noch immer nicht abgeschlossen. Mittlerweile ist zwar jedes relevante Python Paket kompatibel mit Python 3, aber viele Projekte fangen nun an, alte Python 2 Abhängigkeiten/Workarounds auszubauen.

Bei Python hat es sich vermutlich am Ende trotzdem gelohnt, Python 3 ist in vieler Hinsicht besser und zukunftstauglicher als Python 2.

Natürlich entwickeln sich Sprachen weiter (die meisten heutigen C-Programmierer werden ein "K&R Style" C Programm kaum noch lesen können), es gibt aber viele Wege das "verträglich" zu lösen.
Eine Möglichkeit ist z.B. neue Versionen der Sprache auf Modulebene zu aktivieren.

Z.B:

<script type="module">
        import {mq_start} from './mqclient.js';
        await mq_start();

 </script>

Lade ich hiermit ein ES6 Modul. Da sich ES6 Module und "klassiches" Javascript einen globalen Namensraum teilen kann ich trotzdem in Kontrollfluss zwischen den Welten umherspringen.

In C/C++ ist das ABI (Application Binary Interface) zwischen verschiedenen Versionen der Sprache kompatibel, d.h. Calling Conventions, Registerbelegung, etc. bleiben gleich. Daher kann man über Compilerdirektiven (z.B. -std=c99 beim GCC) den verwendeten Sprachstandard bestimmen und trotzdem die Module später noch miteinander linken.

Über solche Mechanismen können sie Sprachen weiterentwickeln ohne dass man existierende Codebasen zwingend überarbeiten muss.

Nur erfordert dass viel Planung und z.B. bei Sprachen wie C/C++ auch Abstimmung in Standard Gremien. Man kann also nicht einfach mal so "Ad-hoc" ein neues Feature einführen.

 

[gymfan]

Das Kritische an einem "breaking change" ist m.M.n. nicht der Umstiegsaufwand auf die neue Version, weil man auch mit der bisherigen weiterarbeiten kann.

Man kann nicht immer damit weiterarbeiten. Außer man bleibt im abgeschotteten, stillem Kämmerlein, bei dem einem die Sicherheit der zwingend zur Sprache gehörenden Frameworks egal ist.

Viele mögen PHP nicht als Programmiersprache bezeichnen, aber mir graut jedesmal, wenn mein Webservice-Provider wieder eine Nachricht verschickt, dass er es aufgibt, die alte Version zu unterstützen. Das hat (zum Glück nur für mein Hobbyprojekt) jedesmal zu hohem, aus meiner Sicht völlig unnötigem Test- und Entwicklungsaufwand geführt.

Wie TomH22 richtig schreibt, besteht eine Programmiersprache nicht nur aus der Sprachdefinition, sondern mind. auch aus dem zugehörigen Framework. Man müsste glatt mal ermitteln, wie oft die (g)libc durch inkompatibele Nachfolger ersetzt wurde.

Nachdem ich mir das "Spiel" mit .NET einige Zeit angesehen habe, bin ich heilfroh, immer noch beim Framework 4.8 geblieben zu sein. Warum soll ich alle 2-3 Jahre meine komplette Software umschreiben (und dabei natürlich auch neu testen), weil es für die alte Runtime keine weitern Security-Updates gibt, ich die neuen Features aber nicht benötige. Die SW hat sich, bis auf ein paar Bugfixes, die letzten 9 Jahre nicht geändert und so lange MS oder Wine das alte Framework noch unterstützten, wird das vermutlich auch so bleiben.

 

[BeBur]

Es geht auch nicht nur um den eigenen Code. Bei breaking changes müssen ggf. auch die Abhängigkeiten (irgendwann) umstellen. Wenn die das nicht alle machen, dann hat man ggf. nochmal mehr Extraaufwand oder auch ein großes Problem.

In C/C++ ist das ABI (Application Binary Interface) zwischen verschiedenen Versionen der Sprache kompatibel, d.h. Calling Conventions, Registerbelegung, etc. bleiben gleich. Daher kann man über Compilerdirektiven (z.B. -std=c99 beim GCC) den verwendeten Sprachstandard bestimmen und trotzdem die Module später noch miteinander linken.

Ist das so? Soweit ich weiß ist die ABI bei C++ nicht stabil (jdfs. im Vergleich zu C).

Das Kritische an einem "breaking change" ist m.M.n. nicht der Umstiegsaufwand auf die neue Version, weil man auch mit der bisherigen weiterarbeiten kann. Sondern der Umstand, dass die Sprache offensichtlich in einer problematischen Sackgasse gelandet ist, aus der sie sich nicht anderes befreien kann. Und in Folge auch der eigene Code.

Es hat leider noch niemand eine perfekte Sprache erfunden, von daher wird das auch so bleiben.

 

[Micke]

ok, zusammenfassend Kompatibilität vor Weiterentwicklung. Ist eine Antwort, danke.

d.h. lieber 5 / 2 = 2 als 2.5 (Python)

Eine Möglichkeit ist z.B. neue Versionen der Sprache auf Modulebene zu aktivieren. ....... [oder] das ABI

Eben und andere Sprachen bieten vergleichbares. Sind damit eigentlich Optionen die die Abneigung senken sollten.

Streng genommen kann schon die Einführung eines neuen Keywords ein breaking change sein,

Das wird vermutlich der verbreitetste Fall sein. Ist aber gleichzeitig trivial zu bewältigen.

ok, unerwartet aber interessant.

 

[BeBur]

Mit so einer passiv-aggressiven Art wirst du jedenfalls nichts dazu lernen.

 

[Maviapril2]

Ein Hauptproblem bei Breaking Changes ist halt der Zeitinvest. Wenn ich jedes Jahr oder alle paar Jahre je nach Umfang der Programme Tage bis Monate bis Jahre investieren muss, um sie am Laufen zu halten, dann ist es eher unschön, weil man dann für die eigentliche Weiterentwicklung (also neue Features einbauen, absichern etc.) keine Zeit mehr hat.

Klar kann einem eine neue Version das vereinfachen, bzw. unsichere Codekonstrukte direkt verhindern.

Meiner Meinung nach ist es am besten, wenn neue Features parallel zu alten Features verwendet werden können. Dann muss man den Code nicht umstellen, man kann es aber. Und man kann externe Abhängigkeiten auch erstmal weiter nutzen

Und wenn man den Code eh aus anderen Gründen anfassen muss, dann kann man es auch umstellen, wenn es einfach möglich ist. Aber nach dem eigenen Zeitplan, nicht einem von außen vorgegebenen

 

[andy_m4]

ok, unerwartet aber interessant.

Du hast übrigens nicht auf die offenen Fragen geantwortet. Was für Dich "Breaking Changes" sind und ob Du da ein konkretes Beispiel für hast.
Ist ja nett, wenn man diskutieren will. Aber dann sollte man sich als Diskussionsstarter(!) auch irgendwie an der Diskussion beteiligen.

 

[Marco01_809]

Kompatibilität vor Fortschritt

Was ist fortschrittlich daran bestehende Programme regelmäßig umschreiben zu müssen nur um die gleiche Funktionalität zu erhalten? Ganz im Gegenteil könnte die Arbeitszeit ja auch anderswo für echte Verbesserungen investiert werden...

Ich nutze eigentlich sehr gerne moderne Schnittstellen und gebe auch nicht viel auf Kompatibilität mit alten Versionen einer Sprache wenn ich ein neues Feature wirklich brauchen kann. Ich breche nur nicht grundlos Kompatibilität. Wenn etwas deprecated wird dann kommt das direkt auf die Liste das bei der nächsten Gelegenheit zu modernisieren.

Das hat aber keine Priorität, denn ich habe ja nicht nur eine Software um die ich mich kümmere, sondern mehrere Projekte die jeweils aus einem System von Softwares bestehen die aufeinander aufbauen. Und ich finds wenig amüsant wenn man mir ständig das Fundament wegsprengt.

Wie schon mehrmals angemerkt muss man unterscheiden wie dieser Breaking Change denn daher kommt.

• Mit wie viel Vorlaufzeit wurde er angekündigt? => Länger ist besser da es mehr Gelegenheit gibt die Änderungen zu machen wenn sowieso mal größere Änderungen fällig sind. Ab und zu kommt es auch vor dass irgendwas deprecated wird aber bevor es endgültig entfernt wird braucht man die ganze Software gar nicht mehr weil sich die Anforderungen geändert haben - z.B. weil anderswo was modernisiert wurde. Da wäre ja schön blöd ich hätte meine Zeit voreilig mit Maintenance verschwendet.
• Wie umfangreich sind die nötigen Änderungen? => Reden wir von einer Syntax-Änderungen die ich mit Find&Replace umsetzen kann oder von der Entfernung einer Datenbankschnittstelle wo ich 10000 Zeilen umschreiben muss?
• Oder er wurde gar nicht angekündigt und es gibt erst zur Laufzeit einen Fehler => Im Regelfall ein Bug. Darum hat man Testumgebungen, Staged Rollouts, u.s.w., dann kann man überlegen einen Workaround umzusetzen oder auf einen Fix zu warten.
• Oder er wurde gar nicht angekündigt, es gibt auch keine Warnung und das Programm hat jetzt ein anderes Verhalten => Das ist ein schwerwiegender Patzer seitens der Entwickler und darf einfach niemals passieren.

Eine gute Sprache/Library zeichnet sich mMn auch dadurch aus dass sie vorausschauend designed wurde so dass Erweiterungen möglich sind ohne Kompatibilität zu breaken. In der Praxis kommt es daher auch selten vor dass man zwischen einem neuen Feature und der Kompatibilität abwägen muss. Der häufigste Fall ist wohl die Einführung eines neuen Keywords wodurch man das Wort nicht mehr als Variablen- oder Funktionsname oder so verwenden kann. Geschenkt.

Der Fall um den es sich zu diskutieren lohnt ist doch eher: Wir haben hier eine uralte Schnittstelle und die ist einfach scheiße weil wir uns vor 5-30 Jahren nicht so viel dabei gedacht haben oder die Anforderungen anders waren. Da gibts auch nichts zu retten, die muss weg. Manchmal gibt es einen besseren Nachfolger, manchmal war das Prinzip aber schon Mist und wir wissen heute das man sowas grundsätzlich nicht macht. Beispiele (absichtlich eine bunte Mischung in Sachen Restverbreitungen): PHP's ext-mysql, IPv4, Java's Thread#stop(), microUSB, jQuery, WEP (bei WLAN), ifconfig auf Linux, 16-Bit/real mode support in Windows.

Linux und Java deprecaten zwar Schnittstellen, entfernen diese aber quasi nie da sie BC breaks grundsätzlich inakzeptabel finden. Trotzdem haben Sie in den letzten Jahren Unmengen an Features dazu gewonnen. Andere Projekte schmeißen Deprecations in der nächsten Major version raus. Wieder andere schaffen es nichtmal in minor releases Kompatibilität zu wahren (hust Python). Auch alternative Lebensmodelle seien an dieser Stelle genannt; Polyfills reinballern bis es auf 99% der Browser läuft oder die ganze app jährlich auf dem neuesten hippen Framework neuschreiben.

Jaja, Richtung Ende wollte ich auch provozieren

 

[jebeo]

Wer nicht privat frickelt, schaut auf Kompatibilität.

 

[Micke]

Ist ja nett, wenn man diskutieren will. Aber dann sollte man sich als Diskussionsstarter(!) auch irgendwie an der Diskussion beteiligen.

Der Thread war als Umfrage gestaltet, um die Grundhaltung einzufangen, nicht sie in Frage zu stellen. Auch weil ich bezweifel, daß sich nach einem Austausch die persönlichen Präferenzen ändern würden. Da werden gute o. schlechte Erfahrungen entscheidender sein.

Du hast übrigens nicht auf die offenen Fragen geantwortet. Was für Dich "Breaking Changes" sind und ob Du da ein konkretes Beispiel für hast.

Ein breaking change kann die Anpassung von abhängigem Code erfordern, um letzteren (wieder) lauffähig zu bekommen. Insofern ist inkompatibler Sprachanteil, welcher per default off ist, kein BC.

Ich kann @Marco01_809 nur zu 100% zustimmen.

dagegen spricht, dass

Klar kann einem eine neue Version das vereinfachen, bzw. unsichere Codekonstrukte direkt verhindern.

Und unsichere Codekonstrukte sind um vieles teurer als BCs. Allein schon weil man BCs planbar in der Dev Umgebung angehen kann, während Bugs im Produktiv System auftreten.
Die Kosten-Nutzen Frage setzt sich fort wenn man bedenkt, daß ein BC häufig von wenigen Teammitgliedern abgefrühstückt werden kann, danach aber das ganze Team effizienter ist. Für die Motivation ist es gleichfalls nachteilig, wenn die Leute umständlichen Code pflegen müssen, obwohl sie bereits von der Vereinfachung wissen.

Meiner Meinung nach ist es am besten, wenn neue Features parallel zu alten Features verwendet werden können. Dann muss man den Code nicht umstellen, man kann es aber. Und man kann externe Abhängigkeiten auch erstmal weiter nutzen

freilich. Aber dann handelt es sich auch nicht um einen BC, womit du kein Dilemma hast

 

[andy_m4]

Der Thread war als Umfrage gestaltet, um die Grundhaltung einzufangen

Das erklärt aber nicht, warum Du offene Fragen nicht beantwortest.
Und Du hast sie übrigens, soweit ich sehe, noch immer nicht vollumfänglich beantwortet. Was ist denn nun das konkrete Beispiel?

Auch weil ich bezweifel, daß sich nach einem Austausch die persönlichen Präferenzen ändern würden.

Es gibt aber 'ne Chance dazu zu lernen und auch neue Perspektiven dazu zu gewinnen. Das ist doch das Spannende dabei.
Ob man deshalb gleich ne Meinung ändert ist eher zweitrangig.

Ein breaking change kann die Anpassung von abhängigem Code erfordern, um letzteren (wieder) lauffähig zu bekommen.

Und zählen nur originäre Sprachkonstrukte dazu oder auch Änderungen in der Standardbibliothek?
Oder die Art, wie Code ausgeführt wird?

Und unsichere Codekonstrukte sind um vieles teurer als BCs.

Es hilft ja schon viel, um diese Schwächen zu wissen. Und wenn man diese Konstrukte mit Bedacht einsetzt und nicht wahllos, dann kann es ja auch ok sein.
Triviales Beispiel: Pointer-Arithmetik in C. Eigentlich eine Sache, die man aus Sicherheitsgründen nicht einsetzen sollte. Aber in manchen Szenarien (hardwarenahe Programmierung) nützlich.

Das einfach nur weg-breakchangen wäre also ein eher suboptimaler Weg.

Die Kosten-Nutzen Frage setzt sich fort wenn man bedenkt, daß ein BC häufig von wenigen Teammitgliedern abgefrühstückt werden kann, danach aber das ganze Team effizienter ist.

Ich will Dir da gar nicht widersprechen. Ich finde nur, das man das pauschal gar nicht sagen kann. Vielleicht bedeutet ein Breaking-Change ja auch, das es ein Konstrukt gar nicht mehr gibt und das dann das Äquivalent gar nicht 1:1 einsetzen lässt. Und/oder Seiteneffekte hinzukommen/wegfallen. Dann kann sie Sache mit dem umschreiben komplizierter werden. Insbesondere bei komplexer Software.

Es ist schwierig dazu was zu sagen, wenn nicht mal konkret benannt wird, worüber man genau redet. "breaking change" ist einfach zu pauschal. Wenn man was mit Search&Replace abfrühstücken kann, sind die Vorbehalte gegen Breaking-Changes geringer als wenn das umfangreichere Änderungen nachsich zieht.

Das ist auch die Schwäche an der Umfrage. Sie erzwingt eine Entscheidung zu einem Thema, für die sich keine pauschale Entscheidung treffen lässt.

Tendenziell haben wir in den Programmiersprachen ja eher das Problem, das sich Features ansammeln und es dann schnell unübersichtlich wird oder so komplex, das man gar nicht alle Features bis ins Detail durchdringen kann. Das führt dann dazu, das jeder Programmierer nur seine "Lieblingsfeatures" einsetzt die aber nicht notwendigerweise die seines Kollegen sein müssen.

Weniger ist daher vielleicht manchmal sogar mehr. Auch wenn das in der ein oder anderen Situation die Dinge umständlicher macht.

 

[Micke]

Und zählen nur originäre Sprachkonstrukte dazu ?

ja

Das ist auch die Schwäche an der Umfrage. Sie erzwingt eine Entscheidung zu einem Thema, für die sich keine pauschale Entscheidung treffen lässt.

Dann wurde die Eingangsfrage schlecht gelesen. Es geht darum einzufangen, ob die Dev Teams von Sprachen grundsätzlich BCs eher progressiv oder zurückhaltend publishen sollen. Da kommt man um eine allgemeine Priorisierung nicht herum, weil man nicht jedesmal eine Bürgerbefragung starten kann. Daß der konkrete BC intern noch zusätzlich bewertet wird ist davon unbenommen.
Auch ein Autobauer versucht herauszufinden, ob seine Klientel eher Sicherheit oder Action bevorzugt.

Tendenziell haben wir in den Programmiersprachen ja eher das Problem, das sich Features ansammeln und es dann schnell unübersichtlich wird oder so komplex, das man gar nicht alle Features bis ins Detail durchdringen kann. Das führt dann dazu, das jeder Programmierer nur seine "Lieblingsfeatures" einsetzt die aber nicht notwendigerweise die seines Kollegen sein müssen.

Weniger ist daher vielleicht manchmal sogar mehr. Auch wenn das in der ein oder anderen Situation die Dinge umständlicher macht.

Da bin ich gerade nicht sicher, ob du noch das Fixen in Folge eines BC meinst. Da wäre es m.M.n. egal welchen Weg der jeweilige Dev geht, Hauptsache gelöst.
Spielst du darauf an, daß es manchmal zwei Code Wege gibt das gleiche zu erreichen und dort aufräumen?

 

[andy_m4]

Dann wurde die Eingangsfrage schlecht gelesen. Es geht darum einzufangen, ob die Dev Teams von Sprachen grundsätzlich BCs eher progressiv oder zurückhaltend publishen sollen.

Kommt drauf an. Das lässt sich pauschal nicht sagen.
Sagte ich doch bereits. Bevor Du unterstellst das andere nicht richtig lesen, solltest Du vielleicht mal bei Dir selbst anfangen.

Da bin ich gerade nicht sicher, ob du noch das Fixen in Folge eines BC meinst.

Wenn ein Sprachkonstrukt gestrichen wird weil es beispielsweise unsicher ist und es dann nur Ersatzkonstrukte gibt, dann hast Du halt Portierungsaufwand.

Evtl. spielst du darauf an,

Ich spiele auf nichts an. Ich meine es so, wie ich es gesagt habe.

 

[BeBur]

Ich glaube, Menschen unterschätzen auch gerne mal die Komplexität der Thematik "Änderung an einer Programmiersprache vornehmen." Ein schönes Fallbeispiel ist Julia: Curry underscore arguments to create anonymous functions. Da wurde ewig lange sehr viel diskutiert und letztendlich hat man keine Lösung entdeckt, die als hinreichend zufriedenstellend erachtet wird.

So geht es bei breaking changes auch schnell. Man müsste Menschen mit großer Python Codebase fragen wie das so für die ist. Soweit ich das verstehe, hat Python öfters mal breaking changes. Und man müsste sich anschauen ob die Probleme bei der Migration von Python2 zy Python3 wirklich der C-API geschuldet waren oder auch der Sprache an sich.

Stellt sich auch die Frage was man (allgemein, nicht unbedingt Python) tut, wenn eine Dependency nicht zur neuen Version migriert, aber eine andere Dependcy die neue Version zwangsläufig benötigt. Solche Konflikte können auch generell auftreten, aber die Sprache ist ja das Kernelement von Software, auf das alles aufbaut.

Vielleicht bedeutet ein Breaking-Change ja auch, das es ein Konstrukt gar nicht mehr gibt und das dann das Äquivalent gar nicht 1:1 einsetzen lässt. Und/oder Seiteneffekte hinzukommen/wegfallen

Stellt sich ja die Frage wieso ein BC überhaupt notwendig wird. Ein neues Feature ist ja erstmal kein BC, sondern ein Zusatz. Wenn aber ein BC notwendig wird ist man denke ich schnell da, dass sich das nicht mehr trivial umbauen lässt.

Generell ein Thema bei dem man sich überlegen sollte, inwiefern man die Tragweite der Problematik kennt bzw. abschätzen kann (ich sicherlich nicht lacht/weint in C++).

 

[andy_m4]

Noch eine kleine Ergänzung zu:

Wenn aber ein BC notwendig wird ist man denke ich schnell da, dass sich das nicht mehr trivial umbauen lässt.

Ja. Möglicherweise. :-)
Um aber doch noch mal ein Beispiel dafür zu nennen, wo ein Breaking-Change eher harmlos im Sinne des Portierungsaufwands ist, ist die Einführung eines neuen "Befehls". Wenn der irgendwo vorher als Bezeichner verwendet wurde, hat man natürlich ein Problem. Aber das lässt sich relativ leicht fixen.