Discussion :

[djo.mos]

Salut
Spring Source a décidé de changer leur politique de maintenance de Spring Framework à partir de Séptembre 2008 comme ceci:

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 ...

Par version de maintenance, on désigne les versions du genre 2.5.1, 2.5.2, etc. pour la branche Spring 2.5.
Spring 2.6 ou Spring 3.0 par exemple sont considérés comme des versions majeures.

Autre précision : les mises à jours seront toujours disponibles dans le code source public de Spring, même après les 3 premiers mois. Mais Spring Source ne publiera plus des versions officielles que pour ses abonnés après ce délai.
Il reste donc possible de récupérer les sources de produire une version à jour tout seul.

J'en parle avec plus de détails dans ce billet.

Dès lors, on est en droit de se poser quelques questions :
Que pensez vous de ce changement de politique ? Pensez vous que ça nuit à Spring Framework et/ou à ses utilisateurs ? Spring Source aurait elle pu agir autrement pour pourvoir faire de bénéfices avec leur produit phare ? Considérez vous toujours Spring Framework une alternative viable ? etc.


Bref, merci de laisser votre avis par la suite pour qu'on en discute.

[Hikage]

Pour ma part, je suis assez partagé.

Les bugfixes et autres seront toujours accessible dans le dépôt, donc au final les corrections sont toujours disponibles.
La seule chose qui change, c'est les releases binaires mineures.

Autrement dit, quand un certains nombres de corrections ont été effectuées sur le tronc, un tag est créé, un binaire compile et packagé, une mise à jour du site et la publication sur les dépots Maven réalisée.
Bref, même si cela peut prendre du temps, cela doit faire en gros quelques heures je pense.

Par contre, je peux comprendre qu'ils ne veulent pas s'amuser à backporté tout les bugfix dans les xxxx versions précédente.

J'aurai mieux compris une politique comme celle ci :

Des releases binaires de maintenances des versions majeures de Spring antérieur à la dernière version ne seront fournies que pour les client payants de SpringSource et ce pendant 3 ans.

En gros, quelles différences ?
Lors de la sortie de Spring 3.0, aucuns nouveaux binaires 2.5.x ne serait proposé officiellement. Le code source serait par contre toujours disponible.

Résultat, tout client ne voulant pas migrer vers Spring 3.0 aurait le choix :

1. Récupérer les sources du dépot et les compiler à leur frais
2. Devenir client SpringSource et avoir accès à ces corrections sous formes de binaires automatiquements ( et suffisement testé pour assurer qu'aucun effet de bord apparaitra ).

Actuellement, je vois bien le risque de voir apparaitre des forks fantômes de Spring, une copie synchrone du projet original, destiné à produire les fameux binaires de temps en temps.

Et ca, plus que le reste pourrait nuire à Spring à mon avis.


Maintenant, ce n'est que mon avis. Le problème sur le sujet, c'est qu'il reste énormément de flou. Beaucoup de monde comprends à sa manière la nouvelle politique de maintenance.
Je pense que SpringSource devrait faire un communiqué, clair et précis, expliquant les tenants et aboutissants de celle-ci. Ce qui change, ce qui reste.

[slevy]

Rien de très choquant pour moi.
SpringSource est une société qui innove beaucoup et qui propose une suite de produits cohérente et complète, tout cela a un coût. C'est normal qu'ils cherchent a monétiser tout ce travail. Après ça va dépendre aussi des tarifs pratiqués...
Le code reste disponible, c'est important.

[djo.mos]

Rien de très choquant pour moi.
SpringSource est une société qui innove beaucoup et qui propose une suite de produits cohérente et complète, tout cela a un coût. C'est normal qu'ils cherchent a monétiser tout ce travail. Après ça va dépendre aussi des tarifs pratiqués...
Le code reste disponible, c'est important.

Oui, mais là, c'est plutôt chercher la bête
Sérieusement, le plus dûr sera toujours fait, i.e. développement en continue d'une branche + commits des bugs fixes dans le trunc.

Donc, que Mr Rod Jhonson vienne nous dire que lancer un simple mvn deploy leur coute des millions de dollars par année, ça je comprends pas
Comme quelqu'un l'a justement marqué sur TSS, c'est plus pour ennuyer les non-payants qu'apporter du plus aux clients payants.

[julien.dubois]

Je bosse pour SpringSource : désolé si vous avez le sentiment que nous n'avons pas beaucoup répondu à cette polémique, mais ce n'est pas nous qui l'avons déclenchée ou nourrie. Personnellement j'accorde peu de temps pour les rumeurs, voire les imbécilités que l'on dit sur Spring (Spring change de licence, Spring n'est pas compatible J2EE, et j'en passe). Je préfère passer mon temps sur nos projets ou chez les clients.
Ceci dit : oui nous allons privilégier les clients et partenaires par rapport aux autres. C'est d'ailleurs déjà le cas depuis longtemps : les clients ont des releases plus tôt, avec des correctifs sur mesure. Ils ont aussi des outils en plus, des garanties, etc... C'est d'ailleurs pour cela qu'ils nous prennent des contrats.
Par contre, ce qui est nouveau, c'est que nous avons maintenant définie notre politique de maintenance. Pour contre-dire djo.mos : oui, on nous demande de backporter des fixes dans du Spring 1.2. Nous supportons toujours cette version, et beaucoup de nos clients ne changent pas de version tous les ans. Et ce genre de chose a un coût, quoi qu'on en dise. Il faut dire que nous avons maintenant beaucoup de projets et beaucoup de versions. S'assurer que tout fonctionne bien, ce n'est pas forcément simple.
Par ailleurs, et pour reprendre Gildas sur les forks : cela existe déjà. Il y a plusieurs sociétés qui proposent du support Spring (j'en connais 4 en France personnellement, et je me souviens d'un post de Rod sur OpenLogic qui était dans le même sens). Ces gens là ne contribuent pas au code, et généralement n'ont même aucun contact avec nous. Ils restent à attendre que nous corrigions le code, pour ensuite le repackager et le revendre à leurs clients - d'ailleurs c'est plus un mauvais repackaging qu'un fork au sens propre du terme. Alors oui, notre nouvelle politique va ennuyer ces gens là : ceci dit, on ne peut pas considérer qu'ils contribuent à grand chose dans notre communauté.
Si vous avez des questions précises sur la maintenance, je vous propose de m'envoyer cela par mail, en Anglais, avant demain midi : le soir je dois voir Mark Brewer, notre VP du support, qui est de passage à Paris. Je pourrai lui transmettre vos questions, et lui demander d'y répondre "officiellement".

[djo.mos]

Merci Julien d'avoir participé à cette discussion

Donc, pour éclaircir ma position : oui, c'est tout à fait naturel et compréhensible qu'une boite arrête de maintenir les anciennes versions de ses softs. Dans le cas de SS, arrêter le support gratuit de Spring 1.x et même 2.0.x ne pose pas le moindre problème. Ce serait même de l'égoïsme et complètement irresponsable que les utilisateurs non-payants exigent le contraire ! Nous sommes bien d'accord sur ce point.

Mais ce qui s'est passé avec le changement de stratégie c'est autre chose : de la dernière version qui ne sera plus officiellement distribué une fois les 3 premiers mois écoulés. Et encore, ceci aurait au moins le mérite d'être calir et net, mais qu'on continue de travailler sur le repository public mais qu'on refuse simplement de lancer un build et de donner un aspect officiel à une release donnée, j'arrive pas à comprendre l'utilité :

Ca ne bloque pas vraiment les utilisateurs non payants car ils pourront faire le build eux même.
Ca n'a rien ajouté aux clients payants.
Ca ne fera que nuire à Spring et à son image dans le monde Opensource : multitude de versions non officielles, image ternie, etc.

[djo.mos]

Les bugfixes et autres seront toujours accessible dans le dépôt, donc au final les corrections sont toujours disponibles.
La seule chose qui change, c'est les releases binaires mineures.

Autrement dit, quand un certains nombres de corrections ont été effectuées sur le tronc, un tag est créé, un binaire compile et packagé, une mise à jour du site et la publication sur les dépots Maven réalisée.
Bref, même si cela peut prendre du temps, cela doit faire en gros quelques heures je pense.

Non, le problème ne vient pas de là, un simple mvn deploy fera l'affaire, on le sait bien.
Mais, une release n'est pas qu'un simple jar : c'est beaucoup plus, c'est un référentiel sur lequel on peut se baser.
Franchement Hikage, dans ta boite, que dirait ton CP ou supérieur en général si tu lui demandes d'intégrer un snapshot que tu as compilé toi même ?

Par contre, je peux comprendre qu'ils ne veulent pas s'amuser à backporté tout les bugfix dans les xxxx versions précédente.

Oui, ça on est d'accord ladessus.
Seul hic, c'est pas de ça qu'il s'agit avec ce changement : personne ne va leur demander de backporter vers Spring 1.x

J'aurai mieux compris une politique comme celle ci :

En gros, quelles différences ?
Lors de la sortie de Spring 3.0, aucuns nouveaux binaires 2.5.x ne serait proposé officiellement. Le code source serait par contre toujours disponible.

Résultat, tout client ne voulant pas migrer vers Spring 3.0 aurait le choix :

1. Récupérer les sources du dépot et les compiler à leur frais
2. Devenir client SpringSource et avoir accès à ces corrections sous formes de binaires automatiquements ( et suffisement testé pour assurer qu'aucun effet de bord apparaitra ).

+0.5 : je dirais plutôt excepté bug grave ou période (moyennement longue, disons 1 ans ?) dépassé.

Maintenant, ce n'est que mon avis. Le problème sur le sujet, c'est qu'il reste énormément de flou. Beaucoup de monde comprends à sa manière la nouvelle politique de maintenance.
Je pense que SpringSource devrait faire un communiqué, clair et précis, expliquant les tenants et aboutissants de celle-ci. Ce qui change, ce qui reste.

C'est ce que j'arrive pas à comprendre un simple billet blog ou page avec un langage != du langage de bois suffirait largement. Mais non, toujours rien ... juste des rumeurs folles courant sur le net.