Quelle version initiale utiliser ?

Question

Je commence généralement mes projets avec une version 1.0.0. Dès que j'ai rassemblé quelques éléments, je les publie en tant que version 1.0.0 et je passe à la version 1.1.0.

Cependant, cela conduit à une version 1.0.0 utilisable mais pas exactement complète de la plupart des choses que j'écris. J'ajoute ensuite des fonctionnalités et j'arrive à une version décente aux alentours de 1.6.0. De nombreux projets commencent avec la version 0.1.0, qui sera aussi utilisable que ma version 1.0.0.

Que suggérez-vous de faire ? Commencer par la version 1.0.0 ou 0.1.0 ?

Le dernier chiffre ne concerne que les versions de correction de bogues. Vous pouvez considérer ma 1.0.0 comme 1.0 et la 0.1.0 comme 0.1 si c'est plus facile pour vous.

Answer 1

En Versionnement sémantique 2.0.0 fournit l'espace 0.y.z pour indiquer que votre projet n'a pas d'API publique stable :

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.

Il est suggéré de commencer par la version 0.1.0 et d'augmenter la version mineure à chaque changement majeur apporté à l'API publique. Vous pouvez passer à la version 1.0.0 lorsque vous êtes en mesure de contrôler et de gérer de manière appropriée ces ruptures :

La version 1.0.0 définit l'API publique. La façon dont le numéro de version est incrémenté après cette version dépend de cette API publique et de ses évolutions.

L'avantage d'utiliser l'espace 0.y.z est que vous n'atteindrez pas une version majeure élevée, par exemple 142.6.0, au cours du développement initial. L'industrie a pour habitude d'éviter les numéros de version majeurs élevés, en partie pour des raisons de marketing, mais cela ne vous concerne peut-être pas.

Le versionnement sémantique s'applique spécifiquement aux projets ayant des API publiques, mais il est souvent appliqué dans d'autres contextes avec une autre notion de "changement radical", par exemple les changements importants apportés aux interfaces GUI.

Answer 2

Le numéro de version est laissé à votre discrétion. Faites ce qui vous semble logique pour vous et être cohérent. Personne ne dit qu'il faut partir de 0, ou de 0,0, ou de 1,0, ou de 1,1.

De grands programmeurs ont en fait utilisé le système de numérotation des versions comme des blagues locales. Exemples (Wikipedia) :

Depuis la version 3, TeX utilise un système idiosyncratique de numérotation des versions où les mises à jour sont en ajoutant un chiffre supplémentaire à la fin de la à la fin de la décimale, de sorte que la numéro de version s'approche asymptotiquement s'approche asymptotiquement de π. du fait que TeX est maintenant très stable, et que seules des mises à jour mineures sont prévues. La version actuelle de TeX est la version 3.1415926 ; elle a été mise à jour pour la dernière fois en mars 2008

Pour METAFONT :

Metafont dispose d'un système de version. similaire à celui de TeX, où le se rapproche asymptotiquement de e à chaque révision.

Enfin, ce n'est pas tout à fait un numéro de version, mais il est tout aussi intéressant de noter que l'offre publique initiale (IPO) de Google a été déposée auprès de la SEC pour lever 2 718 281 828 dollars (remarquez que e~2.718 281 828).

Ce que je veux dire, c'est qu'il ne faut pas se sentir obligé de suivre la foule. Soyez créatif et cohérent.

Answer 3

Je pense que différents facteurs entrent en jeu. L'impact psychologique/marketing du numéro de version (numéro de version plus élevé => plus de $$$, les gens ne veulent pas acheter une version beta 0.99, etc) doit être pris en compte. Les numéros de version "logiques" peuvent être utiles lorsque l'on travaille au sein d'une grande équipe.

Et j'aime bien la méthode linux qui consiste à avoir des nombres impairs pour les versions instables, et des nombres pairs pour les versions stables.

Answer 4

Lors du choix des numéros de version d'un npm sachez que pour les dépendances listées dans le paquet package.json gammes de semences ne fonctionnera pas en dessous de la version 1.0.0, c'est-à-dire,

"dependencies": {
    "my-package": "^0.5"
}

est équivalent à

"dependencies": {
    "my-package": "0.5"
}

Si vous voulez pouvoir utiliser les plages semver, ou si vous voulez permettre à d'autres personnes de les utiliser, vous devriez commencer par la version 1.0.0.

Answer 5

Cela dépend du projet. Pour les outils de ligne de commande simples, je commence généralement autour de 0.9[.0] car je n'envisage de les publier ou de les empaqueter que lorsqu'ils sont presque terminés (ou prêts pour les tests bêta, en tout cas.) Les projets plus compliqués commencent autour de 0.1[.0] et certains ne voient même jamais la version 1.0. Je considère que la version 1.0 est une version de sortie (ou au moins une version bêta ou candidate à la sortie testée localement) et je planifie en conséquence.

Dans les projets d'équipe, c'est celui qui met la première étiquette de version qui décide :).