De plus,
tu utilises beaucoup le mot "stable" dans ton commentaire.
Chaque développeur a sa définition du mot "stable", certaines librairies sont très stables en master et leurs développeurs ne releasent pas souvent de nouvelles gems, et d'autres c'est l'inverse.
Lorsque tu développes une application Ruby avec des dizaines de gems, utiliser constamment les versions stables des gems n'est pas forcément la meilleure chose, tout comme utiliser toutes les gems en branche "master".
C'est pour cette raison que la philosophie de Bundler laissant le choix au développeur de setter ses dépendances sur une release officielle considérée "stable" ou un dépôt est selon moi bonne.
La seule chose qui compte c'est que les tests unitaires/fonctionnels pour TON application passent pour une version donnée de chaque librairie utilisée (que celle ci soit considérée stable ou instable par son auteur n'a aucune valeur).
[^] # Re: .
Posté par Nicolas Blanco . En réponse à la dépêche Sortie de Bundler 1.0.0. Évalué à 1.
tu utilises beaucoup le mot "stable" dans ton commentaire.
Chaque développeur a sa définition du mot "stable", certaines librairies sont très stables en master et leurs développeurs ne releasent pas souvent de nouvelles gems, et d'autres c'est l'inverse.
Lorsque tu développes une application Ruby avec des dizaines de gems, utiliser constamment les versions stables des gems n'est pas forcément la meilleure chose, tout comme utiliser toutes les gems en branche "master".
C'est pour cette raison que la philosophie de Bundler laissant le choix au développeur de setter ses dépendances sur une release officielle considérée "stable" ou un dépôt est selon moi bonne.
La seule chose qui compte c'est que les tests unitaires/fonctionnels pour TON application passent pour une version donnée de chaque librairie utilisée (que celle ci soit considérée stable ou instable par son auteur n'a aucune valeur).