Quick links: Content - sections - sub sections
EN FR
Quick Search Advanced search
 
Page

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Posted by laurentj on 01/28/2012 17:17

Bonjour,

On va essayer de sortir des versions plus souvent. Cependant, au bout d'un moment, on va se retrouver avec énormément de version à maintenir, si on garde un support aussi long qu'avec les versions précédentes.

Pour rafraichir les souvenirs :

  • le support de la 1.0 a duré 32 mois.
  • le support de la 1.1 va se terminer le mois prochain, se qui correspondra à 36 mois (3 ans)

si on maintient à 36 mois pour les versions stables actuelles, le support de la version 1.2 se terminera en décembre 2013, et celui de la 1.3 en octobre 2014 (voir decembre 2014 pour faire "rond").

Pour la 1.2 et 1.3, sauf si vous pensez qu'on peut faire plus court, je propose de les maintenir à 36 mois. Cela reste donc des "LTS" (long term support).

Et pour les suivantes, je propose que le support soit ramené à 1 an, et que la dernière de chaque année soit une LTS (3 ans).

Si par exemple on arrive à sortir cette année une version 1.4, 1.5, 1.6 : 1.4 et 1.5 seront maintenues pendant 1 an. Et la 1.6, 3 ans.

D'après mes calculs, avec 3 nouvelles versions par an, cela fait au maximum 4 branches maximum à maintenir en même temps.

On essaierai donc de sortir des versions tout les 4 mois : avril, aout, decembre.

Cela vous conviendrait-il ?

Laurent

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #1 Posted by foxmask on 01/28/2012 21:20

oui:)


@GitHub - Forum HaveFnuBB! powered by Jelix - Le Booster Jelix !

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #2 Posted by Nesswaw on 02/01/2012 15:53

Si à chaque version, les nouveutés sont là et interéssantes, pourquoi pas, sinon je suis pas du tout adepte de voir sortir des versions à la Google Chrome ou Firefox, qui sortent tout les 2 mois et qui n'apportent rien de nouveau...

Sinon 3 mois je trouve ça chaud, surtout quand on sait que vous bossez "pas à plein temps" sur le framework, ça laisse pas beaucoup de temps pour apporter des nouveautés.

6 mois serait pas une bonne idée?

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #3 Posted by laurentj on 02/02/2012 14:08

C'est sûr qu'avec des releases plus régulières, elles seront moins fournies en nouveautés. Mais ça permettra aussi de ne pas attendre 6 mois pour utiliser une nouvelle fonctionnalité.

surtout quand on sait que vous bossez "pas à plein temps" sur le framework,

Oui. D'où l'importance pour tout le monde de contribuer ;-)

Sinon 3 mois je trouve ça chaud

oui moi aussi, c'est pour ça que là j'ai mis un exemple avec seulement 3 releases. ce qui fait un mois de plus ;-)

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #4 Posted by laurentj on 02/02/2012 14:40

je voudrais ajouter aussi que même si une release ne comporte pas de nouveautés interessantes, rien n'empêche de rester sur la release que l'on utilise. D'autant plus si on est sur une LTS et que la nouvelle est une STS (Short Term Service :)).

à contrario, si une release ne comporte pas de nouveautés intéressantes, la migration est donc en théorie rapide à faire (il y a moins de chances qu'il y ait des trucs de cassés). Donc cela ne coûte pas grand chose de migrer. Le saut à faire vers la prochaine LTS sera alors un peu moins grand.

Et puis si au final, au bout de 4 mois, il n'y a vraiment pas grand chose, et que l'on estime que ça ne vaut pas le coup, on reportera la sortie.

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #5 Posted by foxmask on 02/02/2012 14:48

je suis pour sortir la 1.5 avec ça ;D

Quoi non ? mais si ! :D


@GitHub - Forum HaveFnuBB! powered by Jelix - Le Booster Jelix !

  [Opened] Re: Proposition d'une nouvelle politique de support et d'une roadmap

Reply #6 Posted by Nesswaw on 03/01/2012 15:54

Bonjour,

Pour en revenir à cette questions de temps.

Pour exemple, TYPO3 faisait des releases toutes les années avec leur lots de nouveautés, améliorations.

Ils ont voulu prendre la vague de la tendance en proposant des versions tout les 6 mois.

Résultat => Ils ont jamais atteint à 100% leur objectifs prévu, ils ont du repousser des nouveautés dans les release suivantes, annuler des beta, repousser un peu les délais...Tout ça à cause du manque de temps...et pourtant ils sont passé 40 dév à bosser dessus...

Dernier cas en date, la sortie de la version beta de TYPO3 4.7, les deux nouveauté les plus attendues ont été abandonnées et repousser à la version 4.8...

Un article en parle => http://www.hemmer.ch/home/actualites/developpement-dactualites/article/126/typo3-et-si-la-cadence-des-mises-a-jour-majeures-etait-trop-elevee-7110.html

Ils parlent aussi que les sites web ne suivant pas du tout la cadence des maj et sautent plusieurs versions avant de se mettre à jour...un point à ne pas négliger.

Du coup est-ce que ça vaut vraiment la peine de sortir une version tout les 4 mois?

A réfléchir, n'hésitez pas à donnez votre avis :)

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #7 Posted by lucky on 03/01/2012 18:20

Bonsoir,

Je suis tout à fait de l'avis de Nesswaw : tant pour les contributeurs que pour les simples "profiteurs" (comme moi ;)), le rythme de plusieurs releases par an serait difficile à tenir à moyen-long terme...

Et oui, même quand on se contente de "suivre", ne serait-ce que pour faire bénéficier ses sites web des dernières évolutions, il n'est pas toujours évident de trouver le temps nécessaire !

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #8 Posted by laurentj on 03/02/2012 09:43

Oui mais à la différence de Typo3, il n'y a pas d'objectif à chaque release. à la date butoir, on sort une version avec les nouveautés qui ont été développé les mois précédents. Si on se fixe des objectifs, c'est clair qu'on y arrivera jamais. Cependant, il y a des nouveautés régulièrement, et plutôt d'attendre un an (voire 2) pour en profiter, là on attendra seulement 4 mois grand max. Par exemple, le cache HTTP est prêt depuis quelques mois dans le trunk, et on peut toujours pas en profiter faute de release.

Alors c'est sûr, ça sera pas tous les 4 mois pile, mais on peut essayer de tenir les delais.

Et pour ceux qui ont peur de ne pas suivre, bah ils peuvent toujours se contenter de suivre seulement les LTS, qui ont un rythme "classique". Dans un projet, il n'y a pas obligation d'upgrader un framework tous les 4 mois, surtout si les nouveautés ne sont pas interessantes pour le projet.

  [Opened] Proposition d'une nouvelle politique de support et d'une roadmap

Reply #9 Posted by sdjenadi on 03/04/2012 15:21

Je comprend que le changement peut bousculer, mais il est toujours nécessaire. Voyez ca comme si on est sur un tapis roulant si on avance pas on recule et si on avance a petit pas on stagne.

Prenez exemple sur codeIgniter, leur changements de version et si fréquent qu'il sont toujours en constantes évolutions, ce qui augmente le nombre de la communauté, car on a l'impression que les gars travaille toujours la dessus.

Vous savez quoi je connais jelix depuis un bon moment (et j'aime beaucoup), mais l'année passé un ami m'a présenté codeigniter, j'y jeter un coup d'oeil, apres un inspection profonde de la chose, résultat, mon opinion était "c'est de la merde ça, il fait tout en moins bien, je l'utiliserais jamais". Aujours'hui, je songe a peut-etre l'utiliser, car sa communauté est grande est le nombre de composants developper est impressionnant. Surtout que lui c'Est un nouveaux arrivant, comparer a jelix, il est née de la derniere pluie.

Alors moi ce que je pense c'est arretons de trainer de gros boulet (pendant 3 ans) et investissant plus de temps dans les performance.

Pour moi un LTS = 1 an pas plus.

Vous savez quoi, peut-etre avant, le rythme des release était bien, mais pas aujourd'hui et encore moins demain. Les changement de technologies sorte a tous les jours, du au grand nombre de devloppeur.

 
Page
  1. Proposition d'une nouvelle politique de support et d'une roadmap