Discussion :

[Goten]

Salut à tous,

bon ben tous est dans le titre hein. La 1.43 toute chaude est là.

http://www.boost.org/users/download/version_1_43_0 (release note).

A noté la sortie de deux nouvelle bibliothéques, notemment functionnal/forward qui adresse le problème de forwarding bien connu.

[poukill]

C'est bête comme chou, mais j'arrive plus à suivre boost, les versions sortent trop vite !
J'ai l'impression que la 1.40 que j'ai sur mon PC c'était hier...

Plus sérieusement, j'ai parcouru les docs des nouvelles bibliothèques, c'est pas très causant quand même...
Celà dit, je pense que tout le monde a une factory quelque part dans son code, donc ça devrait intéresser les gens ça. Perso, ma factory était déjà à base de map<string, boost::function>, donc je sais pas trop si je vais m'y mettre. Faut regarder plus en détail !

[3DArchi]

C'est bête comme chou, mais j'arrive plus à suivre boost, les versions sortent trop vite !

Pareil. Ca donne le tournis.

[Goten]

Y'a tellement de bibliothèques dans la review queue que c'est tant mieux....Sa permet d'avoir des nouvelles bibliothèques à presque toute les releases. Et c'est bien car y'a des trucs bien puissant dans la queue...

[thoratou]

Et c'est bien car y'a des trucs bien puissant dans la queue...

Faudra eviter ce genre de double sens par la suite

[Joel F]

bah une release par quarter, ca va c'ets pas la mort :o

[3DArchi]

bah une release par quarter, ca va c'ets pas la mort :o

Il y a encore beaucoup d'entreprise avec Visual 6. Alors essayer de faire rentrer une bibliothèque qui propose une nouvelle version tout les 3 mois, c'est pas si simple.

[koala01]

Salut,

Il y a encore beaucoup d'entreprise avec Visual 6. Alors essayer de faire rentrer une bibliothèque qui propose une nouvelle version tout les 3 mois, c'est pas si simple.

Je sais que certains logiciels ont la peau dure, mais, l'un dans l'autre, tu ne crois pas qu'il peut être intéressant, sans forcément oublier les enseignements du passé, d'envisager de reprendre l'ensemble de la réflexion afin de faciliter l'adaptation aux besoins futurs

Soyons honnête: VC 6 date de... 1998, et en 12 ans, les possibilités offertes par les ordinateurs, et donc, ce que l'on peut attendre d'une application, ont évolué à tel point que l'application telle qu'elle était développée à l'époque pourrait être comparée à une voiture de la fin du XIXeme siècle par rapport à la même application dont nous aurions commencé le développement aujourd'hui. ( on dit souvent qu'un an d'évolution en informatique correspond à dix ans d'évolution dans la vie )

Je suis d'accord sur le fait qu'il faut essayer de garder le support des "anciens" compilateurs aussi longtemps que possible, mais cela en deviendrait presque risible dans certains cas...

D'ici à ce que l'on vienne dire que boost ne compile pas avec Borland C++ 3.0, il n'y a qu'un pas, mais qui l'utilise encore

[gl]

Alors essayer de faire rentrer une bibliothèque qui propose une nouvelle version tout les 3 mois, c'est pas si simple.

Mais le rythme de sortie et-il vraiment un problème dans ce cas ?
Après tout, rien n'oblige en interne à changer de version surtout lorsque ce qu'elle apporte ne nous intéresse pas.

Personnellement, une bibliothèque avec des versions qui arrivent régulièrement ne m'a jamais posé de soucis, bien au contraire. Par contre je ne me jette pas forcément sur la dernière version, surtout pas pour les projets livrés ou en cours de dév.

[koala01]

Mais le rythme de sortie et-il vraiment un problème dans ce cas ?
Après tout, rien n'oblige en interne à changer de version surtout lorsque ce qu'elle apporte ne nous intéresse pas.

Personnellement, une bibliothèque avec des versions qui arrivent régulièrement ne m'a jamais posé de soucis, bien au contraire. Par contre je ne me jette pas forcément sur la dernière version, surtout pas pour les projets livrés ou en cours de dév.

Tout à fait d'accord... il faut voir ce qu'apporte la nouvelle version et décider de changer "en connaissance de cause".

Si les nouveautés ne nous semblent pas indispensables, ou si les éventuelles corrections de bugs s'appliquent à des parties inutilisées, il n'est peut être pas * forcément indispensable * de passer à la version suivante

Par contre, s'il apparait (cela peut toujours arriver ) que les nouveautés proposées sont intéressantes / utiles / indispensables (biffer les mentions inutiles ) à un projet ou que les corrections de bugs s'appliquent à des parties utilisées par le projet, il semble "cohérent" de passer à la nouvelle version... quitte à ne pas *forcément* utiliser la suivante

[gl]

Si les nouveautés ne nous semblent pas indispensables, ou si les éventuelles corrections de bugs s'appliquent à des parties inutilisées, il n'est peut être pas * forcément indispensable * de passer à la version suivante

Par contre, s'il apparait (cela peut toujours arriver ) que les nouveautés proposées sont intéressantes / utiles / indispensables (biffer les mentions inutiles ) à un projet ou que les corrections de bugs s'appliquent à des parties utilisées par le projet, il semble "cohérent" de passer à la nouvelle version... quitte à ne pas *forcément* utiliser la suivante

C'est effectivement l'idée.

Même si dans le cas de la correction de bug, selon l'état d'avancement du projet, j'aurais tendance à envisager aussi la solution qui consiste à simplement introduire la correction dans la version précédente ou, particulièrement dans le cas de boost, ne migrer que la partie concernée de la bibliothèque.

[koala01]

Je donnais effectivement deux exemples extrêmes, mais, comme d'habitude, il y a une série de possibilités qui méritent d'être envisagées entre ces deux points

[3DArchi]

Mais le rythme de sortie et-il vraiment un problème dans ce cas ?
Après tout, rien n'oblige en interne à changer de version surtout lorsque ce qu'elle apporte ne nous intéresse pas.

Personnellement, une bibliothèque avec des versions qui arrivent régulièrement ne m'a jamais posé de soucis, bien au contraire. Par contre je ne me jette pas forcément sur la dernière version, surtout pas pour les projets livrés ou en cours de dév.

Sur le fond, je partage cet avis. Mon seul propos est de rappeler que dans un contexte entreprise, la stabilité des COTS est un critère de décision de choix ou pas. Et une version tout les 3 ou 4 mois ça peut donner l'impression que la bibliothèque n'est pas stable (donc par mûre, donc dangereuse à utiliser) ... même si la plus part du temps il s'agit d'évolution ou de nouveautés. Et qu'il est difficile d'expliquer la nuance à un décideur.

[gl]

Sur le fond, je partage cet avis. Mon seul propos est de rappeler que dans un contexte entreprise, la stabilité des COTS est un critère de décision de choix ou pas. Et une version tout les 3 ou 4 mois ça peut donner l'impression que la bibliothèque n'est pas stable (donc par mûre, donc dangereuse à utiliser) ... même si la plus part du temps il s'agit d'évolution ou de nouveautés. Et qu'il est difficile d'expliquer la nuance à un décideur.

J'ai eu la chance de toujours travaillé dans des environnements où le choix des bibliothèques, frameworks et autres outils est fait par des gens plutôt techniques (architectes, chefs de projet techniques ou responsable R&D) et donc ce style de nuance n'est pas très difficile à faire passer.
Mais j'imagine très bien le mal que l'on peut avoir à faire passer ce genre de nuance à certains décideurs.