[Allegro] CD noch notwendig?

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> So eine stabile Version zu haben wird zunehmend wichtiger, ...
> Das finden wir schon lange. Nur, wie sollen wir umgehen mit den noch
> stets sofort eingehenden, meist dringenden und oft sehr gerechtfertigten
> Verbesserungswünschen, die dann auch umgehend Einzug in diverse
> Anwendungen halten sollen? Das sind ja nicht immer Fehler, die da
> dringend verbessert werden sollen! Wie wir's auch machen, es wird
> unvermeidlich ganz schnell wieder kompliziert.


>> Es gibt immer mindestens eine Regression, also eine
>> Funktion, die schon einmal funktionierte, aktuell aber nicht mehr
>> oder irgendwie anders funktioniert. 
> Das ist übertrieben, und die von heute z.B. war eine recht exotische,
> die in Standardanwendung nicht auftritt. So ist es nicht selten, d.h.

Weit gefehlt: Dieser Fehler tritt nur in U/&%$§"!@@@!XXX; (expletives deleted)
ACWWW 2.5 auf, und es gibt halt Anwender, die das seinerzeit als
Standardanwendung installiert haben und immer noch einsetzen (m.W. ist es
als "Standardanwendung" auch nie zurueckgezogen worden).

Unbedingte Abwaertskompatibilitaet zu jahrzehntealten Versionen ist ein
von allegro-C sehr deutlich getroffene Behauptung (vgl. die Mail von
heute morgen, wo mit dem Verweis auf hypothetische Alt-Anwendungen
ein neulich getroffener "Konsens" [nach meiner Erinnerung: Diese Syntax
*kann* einfach nicht zufriedenstellend funktionieren und blockiert
eine saubere Loesung] in die Tonne getreten wurde).

Mangels einer zusammenfassenden Dokumentation dessen, was beim
Uebergang von dieser zu jener Version geaendert wurde (bzw. konkret
der Punkte, wo unbedingter Anpassungsbedarf durch die Anwender
besteht), ist die Behauptung dieser Abwaertskompatiblitaet allerdings
auch die einzige verbleibende Strategie. Sie muss dann aber nicht nur
die aktuell im Entwicklungsfokus betreffenden Anwendungen betreffen,
sondern eben auch alle Altanwendungen (zumindest die real existierenden).

> man muß Bergers einem (wiewohl stets verständlichen) Verdruß
> geschuldeten Unmutsäußerungen, auch wegen seiner Neigung zu
> scharfkantiger Metaphorik und Übertreibungen, doch ein wenig relativieren.
> 
>> Diese inst-all.exe sind also als
>> (pre-) alpha einzuschaetzen, wehe dem Anwender, der sich so etwas
>> einfaengt.
> Das ist stark übertrieben und kann so nicht stehenbleiben. Wie könnte es
> sonst sein, daß man immer wieder Anwender trifft, die mit irgendeiner
> längst vergangenen "Version" seit vielen Jahren klaglos arbeiten?

Ich streiche mal das "pre". Vom Rest der vorangegangenen Mail behaupte
ich, dass nichts uebertrieben ist. Der Absatz, auf den Sie sich hier
beziehen betrifft die (alle!) Versionen aus den jeweiligen ersten
Halbjahren.


>> Dass Neuanwender typischerweise von CD installieren, hat
>> insofern einen enormen Nutzen und das (der Nutzen, nicht die CD an sich)
>> muss unbedingt erhalten bleiben!
>>
> Dem wäre demnach mit der Bereitstellung einer irgendwie besonders
> gekennzeichneten "echten" Version zu begegnen?

Unbedingt: Parallel zu "aktuelle-version" sollte es ein Verzeichnis
"stabile-version" geben, darin landen ausgewaehlte Versionen und
zwar nach folgendem Schema:
* ein frisches inst-all.exe sollte normalerweise nicht sofort dort
  landen, sondern erst nach einigen Tagen Karenz

* Was dort landet, wird niemals ueberschrieben oder geloescht,
  hoechstens in Unterverzeichnisse verschoben. Insbesondere gibt
  es dort nur Dateien mit Versionsnummer im Namen.

* Zwei Versionen pro Jahr sollten genuegen, eine ist auch o.k.
  Eine README-Datei (wird beim Zugriff auf FTP-Repositories per
  Webbrowser gerne sofort eingeblendet) sollte erlaeutern,
  warum ein 2011er-Abonnent hier (noch) keine V31 findet, obwohl
  das Jahr schon halb um ist.

* "Hotfixes" sind natuerlich nicht auszuschliessen, die sollten
  dann mit an die Versionsnummer angehaengtem "a", "b", "c"
  dazugelegt werden.

Mittelfristig fuehrt m.E. nichts um ein "ueblichen" Entwicklungs-
modell herum: Der Entwickler hat mehrere Saetze von Quellen,
die der "stabilen Version", an der nur noch wirklich schlimme
Fehler repariert werden und der Entwicklungsversion "aktuelle
Version", die gemaechlich auf die naechste Stabile Version hinarbeitet.
Das wuerde dann ermoeglichen, im Fall des Falles auch im Mai 2012
noch eine V31.10x als Hotfix zur V31.10 aufzulegen, auch wenn
die Entwicklung "eigentlich" bereits bei V32.5 angekommen ist.

Netter Nebeneffekt waere, dass alle in einem groesseren Zeitpunkt
zusammengekommenen Neuerungen anlaesslich der Veroeffentlichung
einer "stabilen" Version noch einmal zusammengefasst benannt
wuerden: Ich habe die Abschaffung der allegro-News stets bedauert
(sehe natuerlich, was fuer eine gewaltige Arbeit das war und
kann die Abschaffung verstehen), die zeitnahen "Verlautbarungen"
(Neue Features werden so frueh vorgestellt, dass es noch kein
nennenswertes Feedback geben konnte, moegliche Designverbesserungen
sind dann mit Ruecksicht auf "Altanwender" quasi ab sofort nicht
mehr statthaft) und irgendwelche verbuddelten spaeteren Hilfeseiten zu
neuen Funktionalitaeten sind aber nie adaequater Ersatz dafuer geworden.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkx7fFAACgkQYhMlmJ6W47NaywP5AeUvJxNSbwlI4kUTeyC3uxLP
h1nAyamhLQJ+rQtRyzBsptvand7uvktT767MuNfpIEhD1ulumS0RLXGttXUkVQCW
QhCOUgH8LeQ7XjimIXH7wAI4ND7QRl9ICxR/cvnEsCgaofE5cgOVjtvctGHsR0NS
IbW2Mm7jrzm2m6qbTsY=
=ufTt
-----END PGP SIGNATURE-----