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]

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.

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

[Hikage]

En ce qui concerne les forks, je ne connaissais pas cette pratique. Je peux comprendre que cela fasse raler SpringSource. Je pensais bien que de nombreux soft basés sur Spring existaient, mais de là à ce que des sociétés offrent "le framework et son support" je n'aurai pas cru. Je trouve cela scandaleux aussi ..

Mais par contre, à partir du moment ou le code source est toujours publique, je doute que ça les empêche de vous "pirater". Au lieu de bêtement prendre les jars, il feront un mirroir de votre depot et créeront leur jars.

Personnellement, je ne fais pas partie de ceux qui croient aux rumeurs de changement de licence, etc.
J'essaie juste de comprendre les motivations de cette nouvelle politique.

Je n'ai rien contre le fait que SpringSource privilégie les partenaires, ou utilise Spring comme outils commercial : Les formations, le packaging entreprise ( tool Suite, Spring dm Server, les outils de monitoring, etc ).

Avec un peu de recul, je peux comprendre le choix de SpringSource.
Pour ma part, j'aurai juste laissé les releases de maintenance sur la dernière release majeure.
Toute autres releases de maintenance ( backporting, ... ) serait sujet au support commercial.
Ça aurait rassuré la communauté, sans changer grand chose pour les clients commerciaux je pense.
Car en pratique, une fois une version de Spring utilisée dans un projet, je n'ai jamais remplacé celle-ci par une version de maintenance.

[julien.dubois]

djo.mos, je viens de recevoir ton MP : en fait, nous sommes en train de faire un FAQ, et j'ai rajouté ta question dedans.
A tous : si vous avez des questions, envoyez les moi (en Anglais, ce serait encore mieux), et je les ajouterai à notre FAQ.

[djo.mos]

djo.mos, je viens de recevoir ton MP : en fait, nous sommes en train de faire un FAQ, et j'ai rajouté ta question dedans.

Merci beaucoup pour cette action : Ca aiderait énormément à lever les doutes et à mettre fin aux rumeurs et suppositions qui circulent

Et on apprécie vraiment beaucoup que vous preniez le temps de participer ici Julien : on sait que ces temps sont dûrs et que vous soyez occupé.

A tous : si vous avez des questions, envoyez les moi (en Anglais, ce serait encore mieux), et je les ajouterai à notre FAQ.

A propos de ça, et pour plus de visibilité, histoire d'éviter les questions en double, je suggère de poster aussi les questions ici en plus de les envoyer à Julien par mail (en suivant son profil et cliquer sur le lien "Envoyer un mail ..."

[djo.mos]

Par exemple, la question que j'avais posé était (en gros):

Vu qu'il a été annoncé que les sources seront toujours mis à jour et dispnible publiquement en ligne, ce qui permet de batir sa propre version de Spring, est ce que ce repository public serait taggués à chaque release privée de Spring ?
Exemple, après les 3 premiers mois, disons que Spring 2.5.6 est distribué aux clients SpringSource. Est ce qu'un tag "2.5.6" serait crée dans le CVS public de Spring ? Comme ça, et même si on produit soit même une version de Spring, ce ne serait pas un snapshot quelconque mais plutôt plus ou moins une version offcielle et précise.

Edit

Apparemment pas, selon un commentaire de Rod Johnson dans la discussion sur TSS (sauf erreurs de traduction de ma part):

Il n'y aura pas de tags dans le CVS correspondants à ces releases (en parlant des releases privés aux clients après les 3 premiers mois) ...

(Le commentaire en question)

[dlemoing]

Ne pourrait on pas imaginer la création une branche communautaire au bout des 3 mois ?
Celle ci ne serait pas maintenue par SpringSource et serait à la charge de la communauté. Elle gérerait les reports sur les branches et pourrait contribuer à la correction d'autres bugs.
Je pense qu'il s'agit là d'un moyen de ne pas se couper de la communauté.

[julien.dubois]

Je viens de poster une réponse "officielle" de SpringSource :
http://www.springsource.com/fr/blog/...de_maintenance

Sur notre site US, un FAQ va finir de clarifier tout cela très rapidement.

[Hikage]

Pour information voici la FAQ :
http://www.springsource.com/products...ancepolicy/faq

[tatemilio2]

Bonjour,

Peut on avoir un ordre de prix du contrat afin de bénéficier de la correction des bugs après les 3 premiers mois ?

[julien.dubois]

Concernant l'offre "enterprise", le prix dépend de beaucoup de choses : le niveau de SLA demandé, sur quels produits vous voulez du support (on en a plus d'un!), le nombre de CPUs que vous utilisez en prod (support de prod), le nombre de vos développeurs (support de dév), la durée du support, etc etc... Si tu veux un prix fixe, le mieux est de contacter directement l'équipe commerciale (voir la partie "contact" du site français : http://www.springsource.com/fr ).
Au passage, l'offre de support contient également des outils (STS et AMS), et propose de manière générale beaucoup plus que juste les "corrections de bugs".

[gifffftane]

Deux remarques.

• Je m'aperçois que je télécharge de plus en plus souvent les sources des applis libres que j'utilise. Je trouve ça très intéressant et formateur, et me permet de comprendre beaucoup mieux le fonctionnement (forcément, allez-vous me dire) et la philosophie. Donc cela ne me dérange pas beaucoup que l'on soit obligé de le faire. Par contre, ce qui serait bien serait que cela soit facilité, encouragé. Par exemple que l'on puisse les intégrer directement à son EDI ; le rêve, peut être ? (juste en passant en cas que, moi j'utilise Netbeans et Maven :-)
• La question qui fâche : y a-t-il des alternatives à Spring, qui aient à peu prés le même niveau d'estime du public ?
• Qu'y a-t-il, dans le JDK 6, comme services qui se rapprochent, même de loin, de ce que fait Spring, qui est mieux ou moins bien ?
• Même question pour JEE, mais là j'ai renoncé à savoir à quelle version on en était.

Merci.

(tiens... cela fait 4 questions, finalement)

[djo.mos]

Revirement de la situation :

Rod Johnson (le CEO de SpringSource) vient d'annoncer sur le blog officiel de SpringSource que la limite des 3 mois n'est plus et que les releases officielles de Spring Framework seront toujours rendues publiques jusqu'à la publication et stabilisation d'une nouvelle version majeure (ça suite le trunk quoi).

http://blog.developpez.com/djo-mos?t...nance_spring_b