Nouvelle feuille de route pour Delphi et C++ Builder, vers plus de mises à jour et une version majeure par an

Pièce jointe 217261

Comme décidé en février dernier, Embarcadero publie sous la plume de Marco Cantù sa nouvelle feuille de route semestrielle. L’idée essentielle est de revenir à un rythme annuel pour les versions de l’environnement de développement, avec deux ou trois mises à jour intermédiaires.

En premier lieu, Rad Studio Update 2 est annoncé pour cet automne : incluant de nouveaux styles et contrôles UX, cette mise à jour supportera l’édition anniversaire de Windows 10, en particulier Centennial.

Cependant, plus intéressante semble être la version RAD Studio 10.2 alias Godzilla prévue pour fin 2016 : inclusion des contrôles Konopka et Radiant Shapes rachetés récemment par Embarcadero à la société Raize Software (pour VCL et FMX), RAD Server multi-tenant (multi-tenancy capabilities), support de l’ordre Z pour Android (Firemonkey), QA Automation et surtout le retour très attendu de Linux sous la forme de serveurs Delphi et C++, RAD Server étant dorénavant proposé en version Linux avec intégration d’Apache.

La feuille de route voit encore plus loin puisque la version 10.3 prévue pour fin 2017 porte déjà le nom de Carnival et devrait tout particulièrement s'intéresser à macOS, mais un astérisque rappelle qu’il ne s’agit dans toutes ces annonces que de projections susceptibles d’être modifiées... Aussi nous arrêterons-nous à cette version 10.2, avec la réintroduction de Linux dont les premiers aperçus sont attendus avec impatience par la communauté des Delphistes et des programmeurs C++ Builder !

Pièce jointe 217262

Source : Embarcadero

Bonjour,
par rapport à Qt/C++ et QtCreator cela donne quoi. Quelqu'un a déjà comparé les deux ? c'est juste par curiosité vu que je suis déjà sur Qt je ne vais pas changer.
Bonne fin de journée

Bonjour,

je travaille sur les 2 (sur les 3 avec Lazarus :P). En Delphi je n'utilise FMX qu'à titre personnel, en tant qu'ancien enseignant (une XE 7) et j'utilise Qt/C++ et Lazarus dans une SSII que j'ai créée avec mon père il y a plus de 25 ans, et que j'ai réintégrée il y a peu à la disparition de ce dernier des suites d'une longue maladie comme on dit.

Donc je suis un Pascalien universitaire. J'ai développé épisodiquement (en soutien) pour la société jusqu'à mon abandon de poste d'enseignant. Et avant de partir pendant 3 longues années je me suis formé à Qt (à partir de la version 4.8) difficilement, laborieusement avec des périodes de rejets::mrgreen:. Cela va un peu mieux :roll: Mais l'apprentissage de FMX n'a pas été plus facile, compliqué par mes habitudes en Delphi VCL et Lazarus.

Une énorme limite de Delphi totalement insensée est l'absence de Linux, corrigée partiellement par l'apparition d'une prochaine version "serveur Linux seulement". Alors FMX c'est un énorme potentiel visiblement mais encore mal abouti. On peut difficilement faire des applications Desktop aussi sophistiquées qu'en VCL. C'est pratique par contre pour la réalisation pour les mobiles (sauf processeur Intel.. en voie de disparition paraît-il). A l'époque où je découvrais les capacités de FMX, cela fonctionnait mal sur les mobiles bas de gamme (question de composant vidéo). FMX, c'est léger au niveau du débogage sur les plateformes Mac parce qu'on utilise la cross-compilation. Et FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé le câblage entre un PC et un Mac Mini bas de gamme. :pan:
Car ce n'est pas comme en Qt (ou en Lazarus) où on utilise l'IDE sur la plateforme de développement. Cela à mon avis est un énorme manque. Pour atteindre les bases de données c'est FireDac. Il n'y a pas d'équivalent en Qt. Je préfère utiliser Unidac (qui existe aussi pour lazarus). Les composants graphiques sont totalement obsolètes même s'ils s'améliorent. En réalité la solution vient des composants TMS Software. Certains sont portés sur Lazarus. Le Pdf est mal géré (sauf sous Mac car nativement). Les générateurs d'états sont arriérés quand on les compare à NCreport (voire même Lime) qui coûte pour le premier grosso le même prix que la version complète de la version light qui est offerte dans Delphi et qui est gratuit pour le second. Mais les FastReport (VCL, FMX voire Beta Lazarus) s'améliorent lentement.

En terme de productivité, pour voir les programmeurs C++ ("natifs")/Qt de mon entreprise, on fait pratiquement match nul... sauf quand je réalise une maquette Windev où là, ils sont vraiment à la ramasse. Mais Windev ne produit que du code Windows avec le niveau de sophistication que l'on peut obtenir en Qt (voire en Delphi). Mais si par exemple on veut gérer du texte enrichi, on arrive aux limites de performances de Windev et de Delphi/TMS software... et pas de delegate possible :aie: Alors, à ce moment, la finition demande largement autant de temps que la réalisation en Qt à qualité égale. Ce qui est long en Qt, c'est de constituer ses propres bibliothèques : Dnd entre 2 tableview, SpellChecker dans des QTextEdit...

Par contre, il y a un énorme avantage en Lazarus/Delphi, c'est le déploiement des programmes réalisés. Un exécutable (éventuellement quelques bibliothèque tierces) point final. On fait aussi bien en stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

En conclusion,

• Delphi n'est pas un concurrent de Qt pour le développement Desktop multiOS. D'abord parce qu'il ne gère pas Linux, ensuite même avec l'amélioration apportées par les composants TMS, je le mets au déphi (défi) de gérer du texte enrichi (HTML), de la visualisation, à l'édition et à l'impression. Avec Qt, nous arrivons à faire cela en incorporant même des images encodées en base64 y compris jusqu'à l'édition. Eux, ils en sont au "miniHTML". C'est frustrant.
• Pour le mobile, je ne sais pas, je n'utilise pas Qt pour le faire mais une autre solution. Par contre j'ai pu me rendre compte à titre personnel, que c'était sympa (réellement productif) autant que Windev Mobile.
• Enfin pour le moteur 3D, j'ai eu beaucoup de mal difficultés à comprendre l'approche et heureusement, les membres de ce forum ont été très patients. A l'arrivée, j'ai pu simuler la deuxième Loi de Kepler, avec des images de la Nasa (faites pour), en mettant en évidence l'effet de fronde sur les foyers, en jouant avec l'excentricité, les masses : fabuleux:merci:. J'ai bien vu les exemples fournis avec Qt (Planetarium) mais je ne les ai pas étudiés. Alors qu'avec FMX, le prof de maths et l'informaticien se font un énorme plaisir. Rien que pour cela, j'aimerais soutenir Delphi... Reste, non pas la tarification, mais l'approche commerciale du repreneur et d'ailleurs du précédent... et le soutien aux équipes de développement utilisant leurs produits. Il n'y a que des "vendeurs" dans cette nouvelle structure ?

Enfin une dernière petite remarque concernant les ancrages des "objets" dans les IHM. Lazarus est génial. Delphi est compliqué. Au départ je n'ai pas compris pourquoi... parce que je n'utilisais pas le développement pour les mobiles. Ensuite il a fallu cloner l'approche VCL (largement inférieure à celle de Lazarus) avec les exigences des mobiles. Le résultat est déconcertant mais fonctionnel. Enfin Qt (Qt Creator... on s'y fait. Plutôt efficace et rien de génial).
Et dernière chose qui fait l’intérêt à mon avis de Delphi/Lazarus, c'est l'utilisation des composants à comparer avec la réalisation de plugin sous Qt surtout si on veut les intégrer dans Qt Creator:furieux: On comprend pourquoi la promotion existe en Qt.

Cordialement. AD.

Citation:

---

Envoyé par ApproxDev

On fait aussi bien stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

---

Si je ne dis pas de bêtises :oops:, lorsque tu intègres Qt en statique, tu passes en licence commerciale payante :whistle: :whistle:

Citation:

---

Envoyé par foetus

Si je ne dis pas de bêtises :oops:, lorsque tu intègres Qt en statique, tu passes en licence commerciale payante :whistle: :whistle:

---

Je crois que c'est normal pour une société de développement ? Non ?

De toute façon, j'ai déjà parlé de la tarification à maintes reprises. Ce n'est pas payer qui est un problème mais d'en avoir pour son argent et ce dont on a besoin. VCL ne m'intéresse pas par exemple. FireDac pas plus. Pourquoi je payerais cela ? Mais une assistance technique OK. Une "visibilité" sur Linux Desktop même à 3 ans m'intéresserait et même j'accepterais volontiers d'être beta-testeur. Je n'achète pas un paquet de lessive. Et cela se présente mal aux niveaux des interlocuteurs Delphi: il n'y en a pas ! Je n'ai pas besoin d'un vendeur ni d'un distributeur, j'ai besoin d'un interlocuteur connaissant le produit et faisant interface technique avec non pas son client, mais avec l'équipe de développement qui utilise ses produits.

Il ne faut pas rigoler : avec Windev/Webdev j'ai ce service et PC Soft propose même la possibilité de détacher un de leurs ingénieurs sur site pour plusieurs jours pour renforcer mon équipe... moyennant finances évidemment Si PC Soft faisait également du Linux et du Mac à un niveau égal au développement Windows que permet Windev, je balancerais sans hésitations tous les autres produits que j'utilise parce qu'à mon sens le support est aussi important que le langage utilisé.

Cordialement. AD.

On ne va pas retomber dans les travers de la précédente discussion, n'est-ce pas :mrgreen:

Citation:

---

Envoyé par ApproxDev

Et FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé la câblage entre un PC et un Mac Mini bas de gamme. :pan:

---

Je n'utilise pas FMX et ne connais pas Mac, mais n'y a-t-il pas un Remote Debugger pour Mac ? Est-ce cela qui coince dans la solution câblée ?

Citation:

---

Envoyé par ApproxDev

Enfin une dernière petite remarque concernant les ancrages des "objets" dans les IHM. Lazarus est génial. Delphi est compliqué.

---

As-tu déjà testé le TRelativePanel ? Ce n'est pas encore parfaitement intégré (certains contrôles ne sont pas supportés) mais fonctionne déjà pas si mal. Les composants sont positionnés relativement à d'autres composants, en déplacer ou redimensionner un déplace tous ceux qui y sont rattachés. Et pas de codage, tout ce fait par l'inspecteur d'objet ;)

Bonjour AndNotOr,

La solution câblée ? En réalité, je n'ai jamais su ce qui coinçait...puisque cela n'a jamais fonctionné alors qu'avec le Windows sur le Mac Mini cela a été opérationnel immédiatement mais inexploitable faute de puissance. D'ailleurs "on" m'a vite conseillé d'utiliser Windows en virtual box ou équivalent sur le Mac. Bon j'avais à l'époque une petite réduction sur le Mac (5%) et un prêt à taux nul de part mon appartenance à l'EN; cela a facilité la chose mais quand même !

Pour l'ancrage, j'ai eu des discussions épiques dans ce forum : "Je comprends vite mais il faut m'expliquer longtemps". Si un empilement de layouts dans le cadre d'une "FireMonkey Layouts Strategies" fonctionne en effet impeccablement, on ne peut pas qualifier cela de simple.

Mais bon je le redis, je ne critique pas sur le fond FMX (c'est un produit jeune... et puis sa 3D !) même si à mon avis il faut éviter 2 écueils : une spécialisation vers les mobiles ( peut être incitée par une répartition du CA allant dans ce sens), et une sous-traitance à des sociétés tierces comme FastReport pour des élément essentiels. Mes clients Linux basculent lentement soit vers Windows, soit vers Mac. Donc le Linux Desktop à mon avis ne me sera plus vraiment utile dans 2 ans, voire même avant, alors que le DataSnap sous serveur Linux me serait indispensable si je choisissais l'option Delphi. Mais qui sait ? C'est quand même incohérent de refuser de développer un programme parce qu'un futur potentiel Client fonctionne sous Nux et qu'on n'a pas de plateforme de développement. Delphi compile pour Mac OS (issu d'un BSD) et pour Androïd (issu de Linux), disposera d'une "base" Linux (server only) et ne serait pas capable de produire du Linux GUI ? Voila pourquoi je parle d'incohérence à ce niveau.

Non vraiment le problème, c'est le service. Tout à l'heure j'essayais de construire un bout de code Qt développé sous Linux et construit/compilé avec cmake. Sous Ubuntu 64 et Mint 32, RAS. Sur ma station Windows 7 [64], j'ai besoin d'utiliser le même code, cmake et le Mingw 5.3 [32] de ma Qt 5.7 (pour produire un exécutable compatible XP ultérieurement). Deux tentatives non réussies. Ma société est en vacances. Je poserai lundi la question au support Qt. Je veux pouvoir avoir le même service avec Delphi.

Cordialement AD.

Citation:

---

Envoyé par foetus

Si je ne dis pas de bêtises :oops:, lorsque tu intègres Qt en statique, tu passes en licence commerciale payante :whistle: :whistle:

---

Bonsoir,
contrairement à une idée reçue tu as le droit de faire une liaison statique en licence LGPL à condition de laisser la possibilité au client de changer de version de Qt. Il faut donc fournir un fichier objet de l'application et la procédure pour que le client puisse faire lui-même le changement de bibliothèque.
Evidemment tu peux aussi fournir les sources ;-) mais ce n'est pas une obligation.
Après il est vrai que la liaison dynamique est plus simple, l'utilisateur change lui même la bibliothèque et tu n'as rien à faire (mais interdit sur iOS).
Bonne soirée

Bonjour,

Un peu utopique non ? A partir du moment où votre programme accède à des serveurs, fournir les sources me semble un peu inadapté. Et fournir votre savoir-faire en clair, c'est un peu difficile à défendre économiquement. Chez nous, même la structure de nos bases locales (SQLite) est protégée par SQLCipher (y compris en Qt). Cela a demandé un travail supplémentaire. En Delphi ou en Lazarus avec Unidac, c'est une simple option à préciser dans le composant. :oops: Donc, quand je suis arrivé dans la "boutique", ces structures de bases en clair et la quasi absence de gestion d'exception dans Qt, m'ont laissé baba !

Cordialement. AD.

Citation:

---

Envoyé par ApproxDev

En terme de productivité, pour voir les programmeurs C++ ("natifs")/Qt de mon entreprise, on fait pratiquement match nul... sauf quand je réalise une maquette Windev où là, ils sont vraiment à la ramasse. Mais Windev ne produit que du code Windows avec le niveau de sophistication que l'on peut obtenir en Qt (voire en Delphi). Mais si par exemple on veut gérer du texte enrichi, on arrive aux limites de performances de Windev et de Delphi/TMS software... et pas de delegate possible :aie: Alors, à ce moment, la finition demande largement autant de temps que la réalisation en Qt à qualité égale. Ce qui est long en Qt, c'est de constituer ses propres bibliothèques : Dnd entre 2 tableview, SpellChecker dans des QTextEdit...

Par contre, il y a un énorme avantage en Lazarus/Delphi, c'est le déploiement des programmes réalisés. Un exécutable (éventuellement quelques bibliothèque tierces) point final. On fait aussi bien en stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

---

Bonsoir,
il faudrait peut être voir avec Digia si vous avez le support Qt, pour combler le retard de départ par rapport à Windev non ? et Delphi/C++ Builder pour incorporer les composants dans QtCreator. Par contre en utilisant QML et le designer QML, les composants créés dans un projets sont disponibles dans le designer (car en QML un ficher QML=un objet).

Avec Windev le "10x plus vite" en développement cela ne fonctionne qu'avec des composants tout faits non ?

Bonne soirée

Citation:

---

Envoyé par ApproxDev

Bonjour,

Un peu utopique non ? A partir du moment où votre programme accède à des serveurs, fournir les sources me semble un peu inadapté. Et fournir votre savoir-faire en clair, c'est un peu difficile à défendre économiquement. Chez nous, même la structure de nos bases locales (SQLite) est protégée par SQLCipher (y compris en Qt). Cela a demandé un travail supplémentaire. En Delphi ou en Lazarus avec Unidac, c'est une simple option à préciser dans le composant. :oops: Donc, quand je suis arrivé dans la "boutique", ces structures de bases en clair et la quasi absence de gestion d'exception dans Qt, m'ont laissé baba !

Cordialement. AD.

---

Bonsoir,
non pas besoin des sources, il faut juste fournir un moyen de faire le changement de bibliothèque. Pour windows/Linux/Mac OS Qt en dynamique est suffisant non ? sinon pour le mobile iOS il faut que l'utilisateur puisse faire lui même si nécessaire la liaison statique. Donc la licence LGPL suffit.
Cordialement

Pour l'absence de sources, je ne suis pas convaincu du tout. Mais le problème ne se pose pas ici. Et pour le mobile on n'utilise pas. Donc idem.

On est mal parti sur Windev. Le 10 fois plus vite, c'est du marketing. On n'aime ou pas ce dernier (le marketing). Cela ne me concerne pas. Windev, on l'utilise à la main ou avec le Rad pour débuter. On peut faire ses composants ou pas. Evidemment comme pour Delphi ou Qt, il faut du temps pour l'approcher et maîtriser ce qui fait sa force. Le Rad n'a aucune importance. Franchement, je fais tout à la main avec plaisir tout autant qu'avec Delphi ou maintenant Qt. Mes serveurs de bases propriétaires (HyperFile) tournent sur des serveurs Linux 64 hébergé au même titre que MariaDB ou PostgreSQL. Mon lycée a fonctionné pendant des années avec Windev/Webdev/Hyperfile et je reconnais que cela m'a permis de mener de front mes développements et la maintenance nécessaire sans interférer de quelque manière que ce soit avec mes cours et leur préparation. Je doute qu'en Qt avec PHP/MySQL j'aurais pu en faire autant... à moins d'écourter mes nuits !

Maintenant cette contre-publicité envers les produits PC Soft,

• sert ceux qui les utilisent pour développer...
• permet à ceux qui ne les utilisent pas d'assoir leur soi-disante supériorité en matière de développement....

car je suis sûr qu'on trouve de bons programmes en Qt, Delphi et Windev et de mauvais en Qt, Delphi et Windev. :P
Windev, Qt, Delphi pour moi sont comme Windows, Linux, Mac OS : des solutions toutes aussi intéressantes les unes que les autres, mais de manières différentes.

Pour Qt je ne considère pas qu'il y ait du retard. Il est multiOS, possède son IDE sur chaque OS, gère même mieux le texte enrichi... On peut faire certainement plus personnalisé qu'avec Windev. Mais il est vrai que cela nécessite plus d'efforts au moment du développement. En Windev, la vérification orthographique est intégrée au champs de saisie RTF à condition d'avoir un libre office ou un Word installé sur le poste. On coche simplement l'option. En Qt, il faut intégrer un Spellchecker dans les QTextEdit... A l'arrivée, l'orthographe est vérifiée. Ce qui ne serait pas acceptable c'est qu'on soit obligé en Qt de renoncer à cette option. Et on en fait autant en Delphi (c'est incorporé dans certains composants TMS) et en Lazarus dans les TRichMemo (développé à la main comme en Qt).

Je ne partage pas cette attitude défensive dès qu'on parle d'un produit. Ils ont leurs avantages et leurs défauts. Les chapelles.... pfffff. Pour en revenir à ce que vous qualifiez d'insuffisance, je me rappelle mon premier programme sous Qt : lire un fichier ini. Souvent c'est essentiel au démarrage d'un programme. Sous Delphi/Lazarus, je place une exception un petit try..except..end. Si le fichier est corrompu, le except se déclenche... Et j'arrive avec ma tentative QSettings... Et si le fichier est corrompu, je le sais comment puisqu'on n'a pas d'exception à ce niveau ? "Ben", interlocuteur médusé par une telle question, "un petit m_pLabel(NULL) qui sera rempli lors de la lecture peut te renseigner... par exemple !" :oops: Impeccable et curieuse façon de procéder... Et, ici, on se dispense d'une remarque toute Qtienne : "les exceptions sont pour les nuls qui ne savent pas coder"...:scarymov: Non, c'est une autre approche et le résultat est semblable et garanti à l'arrivée.

Ensuite il y a une stratégie d'entreprise en tant qu'utilisateur. Et là se font les différences... et les choix.

Cordialement. AD.

Citation:

---

Envoyé par ApproxDev

"les exceptions sont pour les nuls qui ne savent pas coder"...:scarymov: Non, c'est une autre approche et le résultat est semblable et garanti à l'arrivée

---

Non c'est l'approche C++ d'une exception. En gros:

• Il y a un léger surcoût en performance lorsqu'on utilise les exceptions (voir point 3)
• Les exceptions sont fait pour remplacer le système "à la C" (voir point 3) "tester à chaque appel le retour (et/ ou un paramètre)". Même malloc
• De centraliser la gestion des erreurs. On lance une exception, elle va arriver gentiment à l'endroit où toutes les exceptions sont gérées (du moins c'est l'idée)

Donc tu mets cela dans une grosse marmite tu touilles et tu voies bien que coller des try/catch partout ce n'est pas le but des exceptions :mrgreen: :mrgreen:.
Puisqu'on se rapproche du système "à la C", et le petit surcoût en performance en plus.

Et même au tout début, on faisait la distinction entre les erreurs qu'on peut gérer plus ou moins facilement (un fichier mal formé, un utilisateur pas présent en base, pas de réseau, ...) et les autres (il manque une DLL, plus de place sur le disque dur, mémoire saturée, pas de réseau, ...)

Et les exceptions étaient surtout utilisées pour les erreurs qu'on ne savait pas gérer: on lançait une exception et le try/catch terminait l'application gentiment. :mrgreen:

Rebonsoir,

Je lance mon programme. Je lis le fichier ini corrumpu. Mon except m'indique qu'il y a un problème. Je ferme le programme inutilisable ou instable. Il n'y en a pas partout !
Sur des chaînes DataAcces-DataControl exploitant des bases distantes sans exceptions, j'imagine mal les méthodes. Idem en Windev qui peut fonctionner sur le même principe que les composants dbXXX de Delphi et Lazarus. Évidemment, l'accès aux bases est totalement différent en Qt donc les exceptions...

OK pour le C++ mais je parle de Qt !... qui a "oublié" de les intégrer : "il" aurait pu mais ce choix n'a pas été fait. Je ne dis pas que c'est bien ou pas. Mon niveau ne me permet pas de trancher.

Quant au C++ sans Qt : aucun intérêt pour notre programmation. Et mon avis personnel sur la question est très tranché : s'il faut faire des programmes sans GUI, j'opte immédiatement pour Lazarus/Delphi, Python, et autres batch ou scripts...
Je ferme pour ce soir.
Cordialement. AD.

Citation:

---

Envoyé par ApproxDev

OK pour le C++ mais je parle de Qt !... qui a oublié de les intégrer

---

N'est ce pas à cause de leur préprocesseur MOC ? :koi: :koi:

Pas d'idée : j'aurai peut-être dû écrire ""il aurait peut-être pu"... sachant quand même qu'il existe quelques moyens d'exceptions en Qt. Mais en Qt j'évite d'entrer dans les entrailles de la bête. Chacun ses capacités.

Cette fois-ci, je ferme... vraiment.
Bonne nuit.
Cordialement AD.

Citation:

---

Envoyé par foetus

N'est ce pas à cause de leur préprocesseur MOC ? :koi: :koi:

---

Je pense surtout que c'est un héritage du passé comme le MOC qui existait avant la/les normes sur le C++ (1998 la première sauf erreur). Et en plus les exceptions coûtent du temps donc...les jeux AAA (les gros titres donc) n'utilisent pas les exceptions pour information

Je vous laisse quelques heures et paf ! ça repart dans tous les sens :weird:

Serait-il possible de vous limiter à commenter la nouvelle roadmap ; ce qui vous plait, ce qu'il y manque, ce que vous désireriez sans systématiquement dévier du sujet initial ?

La plupart des intervenants dans d'autres discussions critiquaient les nouvelles versions trop fréquentes. Il a été décidé de revenir à une version annuelle et des mises à jour régulières ; Embarcadero vous a entendu ! Alors, bonne nouvelle, mauvaise nouvelle ? Plus de stabilité mais des nouveautés retardées ?

C'est là-dessus que j'aimerais vous entendre, pas sur ce que sont capables de faire Qt ou Windev dont je me fiche éperdument :roll:

Citation:

---

Envoyé par Andnotor

La plupart des intervenants dans d'autres discussions critiquaient les nouvelles versions trop fréquentes. Il a été décidé de revenir à une version annuelle et des mises à jour régulières ; Embarcadero vous a entendu ! Alors, bonne nouvelle, mauvaise nouvelle ? Plus de stabilité mais des nouveautés retardées ?

---

On joue sur les mots??? Que cela s'appèle "Berlin 10.2" ou "Berlin update 2", c'est exactement le même cirque!!!

Vu que Embarcadero a décidé de nous entendre :lol: Je profite pour faire une demande: Qu'ils arrêtent de m'envoyer des emails de pub 3 fois par semaine, cela commence à me gonfler...

Citation:

---

Envoyé par NSKis

On joue sur les mots??? Que cela s'appèle "Berlin 10.2" ou "Berlin update 2", c'est exactement le même cirque!!!

---

Je me permets d'intervenir pour rectifier cette affirmation : les updates annoncées correspondent essentiellement à la correction de bogues avec quelques (menues) améliorations tandis que les releases prévoient des modifications de poids : serveurs Linux pour Godzilla 10.2 et plateforme macOS 64 bits pour Carnival 10.3. Finalement, on en revient aux acceptions admises pour ces deux mots alors qu'Embarcadero s'était depuis quelque temps montré obscur sur ce point.
Sachant que la maintenance est à présent incluse dans l'achat d'une licence, que les bogues corrigés le sont aussi pour les versions plus anciennes (depuis peu, hélas !) et qu'une feuille de route (certes, toujours indicative) est proposée tous les six mois, il me semble qu'on ne peut que se féliciter de ce retour à une meilleure visibilité ;).