Delphi Wartung vs. VS Wartung

[Phoenix]

Zitat:

Zitat von greenmile (Beitrag 1274911)

da sich der Release-Zyklus auch bei VS in naher Zukunft verkürzen wird.

Auch so nicht wahr. VS 2010 war Version 11. Von 12 (2012) auf 13 (2013) war es zufälligerweise mal ein Jahr.
VS 14 wird aktuell gegen Mitte 2015 erwartet (1,5 Jahre zur vorherigen Version).

Der 1-Jahres Zyklus hat sich als zu kurz herausgestellt. Die Zeiten werden aktuell also tatsächlich wieder länger.
Was sich hier ändert ist, das es zwischen den Versionen Update-Packs gibt, die auch neue Funktionalitäten hinzufügen. Bei VS 2013 sind wir aktuell schon bei Update 3.

Diese Updates bekommt mal allerdings auch, wenn man seine VS Edition ohne Subscription gekauft hat. Von daher ist eine Subscription nicht unbedingt notwendig.

Die braucht man eigentlich ausschliesslich dann, wenn man die Zusatzleistungen wie die MSDN-Software, die enthaltene TFS Client-Lizenz oder die Azure-Inklusivpakete nutzen möchte. Dann spart man in der Tat richtig viel Geld gegenüber dem Einzelkauf, denn allein schon die TFS-Clientlizenz ist fast nochmal so teuer wie das komplette VS Pro.

[Dejan Vu]

Zitat:

Zitat von jensw_2000 (Beitrag 1274955)

Delphi Komponenten kosten entweder eine Subscription oder 2x pro Jahr wertvolle Arbeitszeit und Nerven.

Wa? Ich hab DevExpress, ohne Subscription. Wechsle aber auch mein Delphi nicht 2x pro Jahr. Ich bin doch nicht blöd bzw. war ich es nicht. Und: Ja, ich hab viel Geld mit damit verdient und nein: Ohne das jeweils neueste Teil zu haben. Eigentlich hab ich das meiste mit D6/7 und BDS(?)2007 (die letzte ohne Unicodestrings als Standard) gemacht. Das sind dann in -glaube ich- 15 Jahren 3 Updates. Geht eigentlich.

Ich arbeite zwar derzeit nur mit VS, aber selbst da wird noch in VS2010 entwickelt. Da die Programme mit VS2010 genauso hübsch sind, wie mit VS2014, hüpfen wir da auch nicht auf die jeweils neueste Version. Demnächst wird schon irgendwann eine aktuelle Version gekauft.

Also: Ich kann immer hinter der aktuellen Version hinterherhecheln oder es sein lassen und mich auf meine Arbeit konzentrieren.

Nebenbei: Bei einer neuen VS-Version hab ich nicht all zu viel Arbeit. Aber auch nur, weil ich nicht all zu viel Zusatzprogramme habe: Resharper, Typemock und DevEx.

[Der schöne Günther]

Zitat:

Zitat von Dejan Vu (Beitrag 1275015)

Ich bin doch nicht blöd bzw. war ich es nicht. [...] Ich kann immer hinter der aktuellen Version hinterherhecheln oder es sein lassen und mich auf meine Arbeit konzentrieren.

Ich wollte diese Woche das größte Projekt von XE5.1 auf XE7 hochziehen. Änderungen an FireDAC, regulären Ausdrücken und XML. Danke für die Motivation. :-D 8-)

[stahli]

@Dejan Vu
Das Problem ist eben aus meiner Sicht, dass man seit D-XE2 nicht mehr auf Updates verzichten kann, wenn man ernsthaft mit D arbeiten will.
Erstens werden die Bugs sonst nicht bereinigt (was ganz klar Emba anzulasten ist) und zweitens ändern sich im mobilen Bereich ständig die Betriebssysteme und Anforderungen (wofür Emba da nun nichts kann).

Ich hatte es früher auch so gehalten, aller paar Jahre ein Upgrade zu kaufen (wenn es was interessantes neues gab).
Das ist aber heute (wenn man mit FMX arbeiten will) kein gangbarer Weg mehr.
Entweder man nimmt alle kostenpflichtigen Updates mit oder man bleibt auf der Strecke.

Gilt natürlich nur alles für FMX. Wer nur die VCL nutzt kann sich wohl erst mal eine Weile zurück lehnen... ;-)

[Dejan Vu]

@Günther: Du bist ja nur dann blöd :mrgreen:, wenn Du das vorher schon von D5 auf D7, dann von BDS2005 auf 2006 und 2007 und 2009 etc. gemacht hast. Einmal sei dir verziehen. Oder..äh..ist das dein Hobby?

@Stahli: Jo, das ist wohl so.

[jensw_2000]

Zitat:

Zitat von Dejan Vu (Beitrag 1275015)

Zitat:

Zitat von jensw_2000 (Beitrag 1274955)

Delphi Komponenten kosten entweder eine Subscription oder 2x pro Jahr wertvolle Arbeitszeit und Nerven.

Wa? Ich hab DevExpress, ohne Subscription. Wechsle aber auch mein Delphi nicht 2x pro Jahr. Ich bin doch nicht blöd bzw. war ich es nicht. Und: Ja, ich hab viel Geld mit damit verdient und nein: Ohne das jeweils neueste Teil zu haben. Eigentlich hab ich das meiste mit D6/7 und BDS(?)2007 (die letzte ohne Unicodestrings als Standard) gemacht. Das sind dann in -glaube ich- 15 Jahren 3 Updates. Geht eigentlich.

Ich arbeite zwar derzeit nur mit VS, aber selbst da wird noch in VS2010 entwickelt. Da die Programme mit VS2010 genauso hübsch sind, wie mit VS2014, hüpfen wir da auch nicht auf die jeweils neueste Version. Demnächst wird schon irgendwann eine aktuelle Version gekauft.

Also: Ich kann immer hinter der aktuellen Version hinterherhecheln oder es sein lassen und mich auf meine Arbeit konzentrieren.

Nebenbei: Bei einer neuen VS-Version hab ich nicht all zu viel Arbeit. Aber auch nur, weil ich nicht all zu viel Zusatzprogramme habe: Resharper, Typemock und DevEx.

Hast voll Recht. Wenn man nicht updated und nur mit uralten Versionen arbeitet sind Delphi + VS gleich teuer. Etwa 0 EUR würde ich schätzen.

[Dejan Vu]

Wer zählen kann, ist klar im Vorteil (0 != 3) und wer lesen kann, auch ('uralt' != ältere Version).

Aber in meinem Beitrag ging es eher um die absurde Idiotie (dafür halte ich es), sich das 2x pro Jahr entweder anzutun oder laut Stahli antun zu müssen. Das es auch anders geht, zeigen eigentlich die meisten größeren Betriebe, die sich eben nur alle paar Jahre mal eine aktuelle Version des benutzten Werkzeugs anschaffen. Ich vermute ja, das da jemand entscheidet, der den TCO im Blickfeld hat.

Und dann ist dann der hier aufgestellte Vergleich vielleicht nicht besonders praxisnah. Aber wer Spaß dran hat, soll es halt machen.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1275008)

Wer es richtig macht, nutzt eine inc Datei, die aufwärtskompatibel ist, so wie Jedi.inc. Da muss man bei Benutzung der DELPHIXXX_UP Direktiven garnüscht ändern.

Wenn man von D6 kommt muss man teilweise aber noch Steinzeit-Technik verwenden.
Werde ich mir aber mal anschauen.

[Uwe Raabe]

Zitat:

Zitat von Dejan Vu (Beitrag 1275027)

Aber in meinem Beitrag ging es eher um die absurde Idiotie (dafür halte ich es), sich das 2x pro Jahr entweder anzutun oder laut Stahli antun zu müssen.

Es gibt aber auch genügend Beispiele, wo das durchaus geht, sinnvoll ist und so gut wie keinen Aufwand verursacht. In meinen Projekten verwende ich ca. 2 Dutzend Bibliotheken und brauche maximal einen Tag, um sie mit einer neuen Delphi-Version zu compilieren - noch bevor irgendwelche Updates dieser Bibliotheken rauskommen. Im Wesentlichen ist es lediglich das Öffnen und Compilieren der einzelnen Projektgruppen, Anpassen des LIBSUFFIX und das Installieren der Design-Packages. Die wenigen Stellen, wo der Compiler eventuell hakt, sind schnell behoben. Dank SA sind die halbjährigen Updates auch keine Kostenfrage. Eigentlich warte ich immer nur auf die passende Version vom ModelMaker Code Explorer, ohne den ich mich schon fast irgendwie verkrüppelt fühle.

Ich will nicht sagen, daß das in allen Fällen möglich ist, nur daß das geschilderte (Schreckens-)Szenario nicht zwingend sein muss und in vielen Fällen durch geeignete Vorbereitungen umgangen werden kann.

[himitsu]

Zitat:

Zitat von Stevie (Beitrag 1275008)

Wer es richtig macht, nutzt eine inc Datei, die aufwärtskompatibel ist, so wie Jedi.inc. Da muss man bei Benutzung der DELPHIXXX_UP Direktiven garnüscht ändern.

Oder man benutzt die schon bei Borland eingeführten Conditional Expressions mit den Konstanten CompilerVersion, bzw. RTLVersion, und kommt ohne eine INC aus.

Früher waren in einigen der INCs, bzw. im System auch "Features" als DEFINEs angelegt, mit denen man arbeiten konnte, anstatt auf eine Version zu prüfen, was auch irgendwie verständlicher war, aber bei Vielen der wirren Änderungen in letzter Zeit, ist das so eh nicht mehr verwendbar, oder schafft Emba es wirklich bei jedem Update auch die RTL-/CompilerVersion zu ändern?
Auf diese Weise war der Code/die Prüfung auch für unterschiedliche Compiler/Bibliotheken (z.B. Delphi, Lazarus, FPC, ...) nutzbar.

Bei meinen Conditional Expressions prüfe ich dann oftmals lieber auf das Vorhandensein bestimmter Typen/Funktionen, damit hab ich mir im Code auch gleich oftmals den Kommentar erspart, was ich eigenntlich prüfen wollte.

Delphi-Quellcode:

{$IF Declared(TEdit)}

/

Delphi-Quellcode:

{$IF Defined(WIN32)}

/

Delphi-Quellcode:

{$IF CompilerVersion >= 20}

Vorallem da man hier ganz praktisch mehrere Prüfungen kombinieren kann, anstatt das Zeug umständlich verschachteln zu müssen.

Delphi-Quellcode:

{$IF Defined(WIN32) and (CompilerVersion >= 20) and (CompilerVersion <= 23)}

Wenn man das mit dem XE nicht eingeführt hätte, dann hätte ich mir eine Integer/Float-Konstante "DelphiVersion" gewünscht.
(Solange das mit dem XE bleibt, oder zumindestens die Nummer nicht mal wieder auf 1 zurückgesetzt wird, wäre das ja immernoch eine Option, wenn man "ab XE" zählt)