septembre
2008
SpringSource, anciennement Interface21, la boite derrière le très populaire Spring Framework vient d’annoncer (en fait, ça date de 2 jours, mais bon …) une nouvelle stratégie de maintenance de leur produit phare (Spring Framework) : En gros, et à partir de Septembre 2008 (nous y somme déjà), les versions de maintenance ne seront disponibles publiquement que pendant les 3 premier mois suivant la sortie du produit. Après cela, les mises à jour qui suivent ne seront disponibles que pour les client payants de SpringSource et ce pendant 3 ans …
La paperasse officielle (ou plutôt les octets officiels ) à propos de ceci :
=> L’annonce
=> La nouvelle politique de maintenance
Bon, la nouvelle politique dit que les bug fixes et compagnie commités après ces fameux trois premiers mois seront inclus dans la version majeure suivante de Spring …
Ceci a bien évidemment suscité une vive polémique (voire même un mouvement de panique) dans la communauté, comme en témoigne la discussion suivante sur The Server Side …
Entre autre, on se posait la question judicieuse de ce que veut dire au juste version majeure …
Marc Brewar, le Vice Président Sénior de SpringSource est ensuite intervenu pour expliquer qu’une version est considérée majeure quand l’un des deux premiers chiffres de la version change (Spring utilise un schéma de versionnage à 3 chiffres). Donc, pour Spring 3.0, Spring 3.1 ou Spring 4.0 sont considérés comme versions majeures. Ouf ! Ca semble un peu moins sombre tout d’un coup …
Rod Jhonson est lui aussi intervenu dans la discussion où il présenté les choses autrement (il sait bien présenter lui ) : En gros, ce changement de politique internvient car avec la multiplication du nombre de versions de Spring utilisés en production augmente, SpringSource ne peut pas continuer à les supporter tous (principalement les back-port de correctifs et fonctionnalités d’une version plus récente à une autre plus ancienne). Or, pour des ceux utilisant Spring et qui ne veulent pas passer toujours à la dernière version de ce dernier (ce qui est normalement le cas avec les entreprises commerciales uniquement), ils peuvent continuer à disposer des correctifs sur ces anciennes version de Spring moyennant un abonnement dans leur programme payant.
Avis personnel : Vu comme ça, c’est pas si mauvais que ça pour la communauté Opensource utilisant Spring. Seul hic … et comme toute entreprise commerciale désirant faire des revenues (c’est leur droit naturellement), je crains que des patchs/nouvelles fonctionnalités ne soient retenues jusqu’à l’écoulement de ces 3 premiers mois …
Ou moins « théorie du complot », disons qu’un bug majeur/brêche de sécurité soit découvert après les 3 premiers mois (ce qui n’est pas du tout invraisemblable : un brêche majeure de sécurité dans Spring MVC a été découverte plusieurs mois après sa sortie), et que la version majeure suivante n’est pas prévue avant encore 6 mois (toujours pas si invraisemblable)… doit on vivre avec ça durant ces 6 mois ?
Bien que je suis profondément deçu par cette décision de SpringSource, je peux parfaitement comprendre leurs motivations : ils ont des employés à payer, ne l’oublions pas, et c’est leur droit de vouloir gagner de l’argent. Ce n’est pas moi qui travaille dans une société commerciale qui développe et vend des applications qui vais m’en offusquer.
Ce qui m’offusque c’est plutôt :
- SpringSource communique très mal la dessus … l’annonce et le texte du changement de politique sont très brefs, vagues, sujet à plusieurs interprétations, surchargés de choses inutiles, etc. Il sauraient pu mieux communiquer cette action au lieu de la clarifier ensuite sur des forums …
- Mais surtout les changements de politique en cours de route. Ca sape la confiance de la communauté dans le produit. Spring Framework a reçu un coup dûr avec cette dernière action, surtout dans le monde des entreprises : C’est devenu un framework à risque, rien n’empêcherait la licence de Spring Framework (Apache 2) de changer dans le futur par exemple …
Conclusion du jour : vais commencer à étudier Guice, on ne sait jamais
=> Exprimez vous dans cette discussion sur le forum !
Edit: Apparamment, les bugfixes et autres seront toujours commités dans le trunk public de Spring, même après le délai des 3 premiers mois (Source : commentaire de Marc Brewar sur ce blog). Seulement, SpringSource ne publierait plus des releases officiels que pour ses abonnés. Mais il reste possible de récupérer la dernière version du trunk et la recompiler à la main.
Seul hic, et avec la communauté Java (sur-zélé :p), ceci va causer une avalanche de versions exotiques de Spring venant d’une multitude de sources sur le net … bonjour les dégâts … ça va chauffer pour le repository de maven
P.S.: Drôle de coïncidence, Peter Mularien vient de publier une étude sur la transparence de Spring Framework …
P.S. 2 : Alexis MP vient de publier un billet sur ce thème.
Si vous voulez en débattre et vous exprimer, merci de le faire dans cette discussion sur le forum.
Merci.
>Qu’est-ce qui se passe si Guice fait la même chose dans 2 ans?
Bah c’est très possible je dois l’avouer
Dans ce cas, j’imagine qu’entre temps, un Spring-killer Opensource serait né …
Mais sinon, Guice était plus une métaphore pour dire alternative
>A part Guice, tu peux aussi faire du Java EE 5 standard…Le standard est source de choix
Yep. C’est une éventualité. D’ailleurs, j’attends impatiemment les WebBeans et les profils Java EE
Mais entre nous, si les gens se sont limités à utiliser le standard et ignoré des choses comme Spring et Hibernate, bah Java EE 5 ne serait pas ce qu’il est maintenant, non ?
Je veux dire que le standard a besoin de ces outlaws pour l’obliger à réagir et à s’améliorer, et ces outlaws ont besoin d’adeptes pour gagner de la traction et influencer les standards.
Au fait, je n’ai rien contre les standards : d’ailleurs, j’ai pas mal travaillé avec JSF 1.x (et je suis activement l’avancement du futur JSF 2), j’adore JPA, même avec Spring je privilégiais @Resource à @Autowired
(c’est leur droit naturellement)
En fait, c’est même leur devoir
A part Guice, tu peux aussi faire du Java EE 5 standard. Qu’est-ce qui se passe si Guice fait la même chose dans 2 ans? Le standard est source de choix…