Commençant par semver `.0`

Ecoute, je comprends. Vous publiez un nouveau package... vous sortez, ne sachant pas si la bibliothèque aura besoin de modifications. Alors vous dites : « peut-être que je devrais publier la v0 maintenant et la v1 plus tard quand elle sera suffisamment prête ». Cet article tentera de vous persuader de publier la v1 dès le début.

Il y a plusieurs raisons de publier la v1 :

• Les versions SemVer 0.x sont différentes
• Soyez confiant et prenez-le au sérieux
• force du projet

Il me semble que les différentes raisons de la v0 se résument à :

• incertitude
• paresse
• manque de compréhension/problème de compétence

...

Mais après avoir lu ce numéro intéressant sur le dépôt Semver : https://github.com/semver/semver/issues/221, mon opinion change. L'utilisation de la version 0.x indique une instabilité, c'est vrai, mais la réalité est que certaines bibliothèques sont instables.

Qu'est-ce que j'entends par instable ? Ce n'est pas que la bibliothèque change (car ces changements peuvent être planifiés et être représentés par des numéros de version majeurs). L'instabilité est liée à la prévalence des bugs.

Les bugs peuvent être :

• bogues logiciels réguliers, ou
• modifications révolutionnaires publiées dans une version mineure ou un correctif.

Remarque : il y a peu de différence entre ces deux-là. De nombreux bugs ne sont que des disparités ou des incompatibilités entre les API.

Alors --- quelle est la probabilité que votre bibliothèque tombe en panne pour les consommateurs ? Seuls les responsables de la bibliothèque peuvent répondre à cette question, et elle s'appuie souvent sur l'expérience de problèmes soulevés au fil du temps par vos consommateurs.

Mais comment savoir à quel point la bibliothèque sera avant de la publier ? Peut-être qu'une période de temps en 0.x est une bonne idée.

Mais la bibliothèque sortira-t-elle un jour de la version 0.x ? Parce que l’inertie est une réalité. Aurez-vous le temps ? Est-ce que cela sera adopté par le comité ? C'est un risque.

D'un autre côté, le risque de la sortie de la version 1.0.0 est que les consommateurs connaîtront une instabilité s'ils mettent fréquemment à niveau. Mais il existe des atténuations à cela. Premièrement, avec les fichiers de verrouillage, la mise à niveau des packages est une action manuelle. Les consommateurs ne sont pas affectés par les problèmes à moins qu'ils effectuent une mise à niveau. Et ils ne peuvent tout simplement pas effectuer la mise à niveau, ou reporter la mise à niveau à plus tard.

Les nouveaux consommateurs peuvent atterrir sur une version boguée, c'est vrai, mais ce serait également le cas dans le système 0.x.

Les bibliothèques comme Storybook ne sont pas très stables entre les versions (d'après mon expérience), et pourtant elles n'utilisent toujours pas la version 0.x. Pour ce que ça vaut.

Et puis il y a le domaine des dépendances transitives. Si votre package est une dépendance d'un autre package, alors cet autre package doit décider quelle plage de semver utiliser. Votre stabilité affecte la stabilité de ce package, les enjeux sont donc plus élevés.

Soit ce package épingle votre bibliothèque, soit utilise une gamme de semver plus large. Dans le premier cas, cela provoque une duplication néfaste pour les performances. Dans le second cas, cela risque d’être instable. Je parierais que la première option est vouée à l’échec et que l’instabilité est toujours un risque.

Je n'ai pas de réponse ici, mais le point principal est que si votre bibliothèque est utilisée par d'autres bibliothèques, les enjeux sont plus élevés et vous devriez probablement vous assurer que votre bibliothèque est stable.

Vous devriez donc essayer d'écrire une bibliothèque stable, mais si elle est instable, continuez et utilisez 0.x jusqu'à ce qu'elle soit stable. Mais si vous le pouvez, utilisez 1.x.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!