AW: BASS-Library
Wo ist denn das Problem? Hier hat ein Nutzer einer "Endbenutzer-Software" - ohne vorher deren Entwickler zu konsultieren - eine neue Version einer Library installiert, die er eigenständig aufgespürt und heruntergeladen hat. Dass die Library nicht zu der vorhandenen .exe passt, weil sich APIs geändert haben, ist nichts Außergewöhnliches. Da trifft den BASS-Entwickler keine Schuld. Im Gegenteil, der arbeitet äußerst vorbildlich, was das Dokumentieren neuer und geänderter Features angeht. Nur muss natürlich erstmal der Entwickler der "End-Software" sein Programm auf die neue API umstellen. Da haben aber die Endbenutzer nichts mit zu tun, solange sie weiterhin die mitgelieferten Libraries verwenden und nicht auf eigene Faust Updates machen.
Jein. Ich sage *nichts* dagegen, daß sich eine API ändert - das ist notwenig und sinnvoll. Und Pegasus, ich spreche auch nicht dafür (steht sogar explizit drin), jeden API-Call von anno Dunnemals bis zum St. Nimmerleinstag in der Library zu belassen. Wenn ein *Endbenutzer* ein Produkt mit einer inkomptatiblen API-Version zu betreiben versucht, ist das in der tat sein Problem. Aber davon habe ich auch gar nicht geredet.
Ich rede davon, daß hier offensichtlich von Version 2.3 zu Version 2.4 der Library so viel geändert hat, daß eine Umstellung der Software notwendig wird, um die neue Library verwenden zu können. Zum Einen hätte ich es besser gefunden, wenn der Entwickler das durch einen großen Versionssprung kenntlich gemacht hätte (also direkt auf 3.0) und (falls nötig) die alte Version mit weiteren 2er Updates. Aber gut, ist sein Nummerierungssystem, ich finde nur, solche Sprünge rechtfertigen eine Große Versionsnummer, selbst dann, wenn nicht auch neue Features mit drin sind.
Zum zweiten reißt er dadurch, daß die alten Calls komplett aus der API verschwunden sind, allen Entwicklern, die darauf aufbauen, den Teppich unter den Füßen weg. *jeder*, der die neue Version nutzen will, *muß* seine Software umschreiben. Diese Friß- oder Stirb-Methode mag ja durchaus verbreitet sein und sicherlich auch sinnvoll, alte Zöpfe wegzuschneiden - aber dadurch könnte er im Zweifel auch Projekte gefährden, je nachdem, wie groß der Aufwand ist, die neue API zu lernen und die darauf aufsetzende Software neu zu entwickeln.
Meinen Lösungsansatz dazu hatte ich ja schon beschrieben: Alte Calls (und Returnwerte) ändern sich zunächst einmal *nicht* sie werden aber ab sofort in der Dokumentation als "deprecated" geführt. Wenn möglich, baut man entweder die neue Funktionalität durch Calls auf die alte API auf (und macht diese dann später irgendwann mal nicht mehr direkt aufrufbar), oder man leitet die alten Calls für eine Weile auf die neuen einfach um, bevor man sie dann in einer zukünftigen Version endgültig löscht, oder, wenn das beides nicht funktioniert, existieren halt für eine Weile alte und neue Version nebeneinander, bis dann die alte irgendwann rausgelöscht wird. Wichtig halt nur, daß alte und neue Calls für eine Karenzzeit parallel existieren.
Der Grundsatz sollte hier meiner Ansicht nach lauten: Interface nur langsam und mit ausreichend Vorwarnung ändern, Implementation kann man jederzeit ändern. Dadurch erlaubt man auch Programmierern, die nicht gleich Gelegenheit haben, ihre Software anzupassen, die neue Library schon zu benutzen. Nach einer Karenzzeit (Vielleicht ein oder zwei Jahre) fliegt dann endgültig alles raus, was zuvor "deprecated" markiert wurde. Diesen Ansatz finde am "fairsten", da er weder den Fortschritt behindert indem er übermäßig lange an alten Zöpfen festhält, noch Benutzer dazu zwingt, von jetzt auf nun ihr ganzes Projekt umzustellen oder auf Gedeih und Verderb der alten (möglicherweise nichtmal mehr gepflegten) Version ausgeliefert zu sein.
Und nu sag ich nix mehr zu dem Thema, da's für den Fred hier nu endgültig OT wird
LG
McCavity