Quoi utiliser comme version initiale?
Je commence généralement mes projets avec une version 1.0.0. Dès que j'ai quelques éléments ensemble, je le publie sous la version 1.0.0 et je passe à la version 1.1.0.
Cependant, cela conduit à la version 1.0.0 complète, utilisable mais pas exactement, de la plupart des choses que j’écris. J'ajoute ensuite des fonctionnalités et parviens à une version décente vers 1.6.0. Beaucoup de projets commencent avec la version 0.1.0, qui sera aussi utilisable que ma 1.0.0.
Que suggéreriez-vous faire? Commencez par 1.0.0 ou 0.1.0?
Le dernier numéro concerne uniquement les versions de correction de bug. Vous pouvez considérer mon 1.0.0 comme 1.0 et 0.1.0 comme 0.1, c'est plus facile pour vous.
Le Semantic Versioning 2.0.0 standard dit:
La chose la plus simple à faire est de commencer votre version de développement initiale à 0.1.0, puis incrémentez la version mineure pour chaque version ultérieure.
Il est bon de passer de 0.3.0 directement à 1.0.0. C'est aussi parfaitement correct d'être à 0.23.0. Commencer à 0.4.0 est quelque peu déconseillé, car cela suggère l'existence de versions antérieures publiées.
De plus, notez que 0.y.z est gardé de côté pour une itération rapide, de sorte que le développement initial (et donc beaucoup de changements radicaux) ne vous laisse pas à quelque chose de stupide comme 142.6.0. Au lieu de remplacer la version majeure, remplacez la version mineure à chaque changement important jusqu'à la version 1.0.0:
La version majeure zéro (0.y.z) est destinée au développement initial. Tout peut changer à tout moment. L'API publique ne doit pas être considérée comme stable.
Le numéro de version est entièrement à vous. Faites ce qui est logique pour vous et soyez cohérent. Personne ne dit que vous devez commencer à 0, ou 0,0, ou 1,0 ou 1,1.
Les grands programmeurs ont en fait utilisé le système de numérotation des versions comme blagues locales. Exemples (Wikipedia):
Depuis la version 3, TeX utilise un fichier numérotation des versions idiosyncratique système, où les mises à jour ont été indiqué en ajoutant un chiffre supplémentaire à la fin de la décimale, de sorte que le numéro de version asymptotiquement approche π. Ceci est un reflet de le fait que TeX soit maintenant très stable, et seules les mises à jour mineures sont anticipé. La version actuelle de TeX est 3,1415926; il a été mis à jour pour la dernière fois en mars 2008
Pour METAFONT:
Metafont a un système de gestion de versions semblable à celui de TeX, où le le nombre approche de façon asymptotique e à chaque révision.
Enfin, il est intéressant de noter que le premier appel public à l'épargne (IPO) de Google a été déposé auprès de la SEC pour avoir collecté 2 718 281 828 dollars (notez que la valeur est environ 2,718 281 828).
Mon point est: ne vous sentez pas obligé de suivre la foule. Soyez créatif et cohérent.
Je pense que différents facteurs entrent en jeu ici. L'impact psychologique/marketing du numéro de version (le numéro de version augmente souvent => plus de $$$, les utilisateurs ne veulent pas acheter une version 0.99 bêta, etc.) doit être pris en compte. Les numéros de version "Logic" peuvent vous aider lorsque vous travaillez dans une énorme équipe.
Et j'aime bien la manière linux d'avoir des nombres impairs pour les versions instables, et des nombres pairs pour les versions stables.
Lorsque j'obtiens ma première version prête à être utilisée mais pas complète, j'essaie normalement de juger de l'évolution de la version complète; ainsi, par exemple, si ma première utilisation est 33% complète, je mets la version 0.3.0 ou similaire. Puis, au fur et à mesure que je me dirige vers les fonctionnalités complètes, les versions correspondantes se voient attribuer des numéros de la même manière.
Mais une fois que vous avez passé la fonctionnalité, la gestion des versions complète doit changer
0.1.0 est ce que je commence avec et monte à partir de là. C’est ce que j’ai adapté pour Xploration By Adrian, même si dans mes premières années, j’étais très sporadique et utilisais 1.0.0, 0.0.1 et quelques autres. Mais je recommande de commencer à 0.1.0 et à partir de là.
Par semaine, réservez a et c dans a.b.c pour A. Votre première version officielle et C. Corrections de bugs et correctifs. En effet, une version majeure rompt généralement l'ancien code. Et les correctifs corrigent simplement les bugs. Toutes les préférences personnelles, 0.99.0 ne signifie pas que vous devez aller à 1.0.0, etc. J'en ai vu qui vont jusqu'à 0.218.42.
Lorsque vous choisissez des numéros de version pour un paquet npm , n'oubliez pas que pour les dépendances répertoriées dans package.jsonsemver, les commandes ne fonctionneront pas sous la version 1.0.0. C'est,
"dependencies": {
"my-package": "^0.5"
}
est équivalent à
"dependencies": {
"my-package": "0.5"
}
Si vous voulez pouvoir utiliser des intervalles semver ou laisser d'autres utilisateurs les utiliser, vous voudrez peut-être commencer par 1.0.0
En général, le contrôle de version a une signification pour le programmeur. L'augmentation du nombre majeur peut indiquer des modifications importantes empêchant la compatibilité avec les versions antérieures. D'autres numéros dans le numéro de version peuvent indiquer des améliorations mineures ou des corrections de bugs.
Si vous craignez que la version 0.6.5 ne sonne pas complètement, vous pouvez la commercialiser sous la version 1.0. Votre numéro de version marketing ne doit pas nécessairement correspondre à votre numéro de version interne. Le numéro de version de Windows 7, par exemple, est 6.1.
Ma préférence personnelle est de partir de 0.1.0 à partir de là.