Que utiliser comme version initiale? [fermé]

Je démarre généralement mes projets avec une version 1.0.0. Dès que j'ai quelques trucs ensemble, je le publie en tant que 1.0.0 et je passe à 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 quelque part autour de 1.6.0. De nombreux projets démarrent avec la version 0.1.0, qui sera aussi utilisable que ma 1.0.0.

Que suggéreriez-vous de faire? Commencez par 1.0.0 ou 0.1.0?

Le dernier numéro concerne uniquement les versions de correction de bogues. Vous pouvez penser à mon 1.0.0 comme 1.0 et 0.1.0 comme 0.1, c'est plus facile pour vous.

Ma gestion des versions est pilotée par la configuration. Je veux qu'il remplace les anciennes versions, donc je continue de l'augmenter par sauts qui me semblent sensés.

Parfois, cependant, la gestion des versions est pilotée par le client, en particulier si vous publiez du code au public.

Si c'est votre appel, faites ce qui vous convient le mieux. J'ai eu quelques problèmes avec les versions antérieures à 1.0, donc je commence par ça.

La norme Semantic Versioning 2.0.0 dit:

La chose la plus simple à faire est de démarrer votre version de développement initiale à 0.1.0, puis d'incrémenter la version mineure pour chaque version ultérieure.

Il est très bien de passer de 0.3.0 directement à 1.0.0. Il est également parfaitement normal d'être à 0,23,0. Commencer à 0.4.0 est quelque peu déconseillé car cela suggère qu'il y a eu des versions publiées précédentes.

De plus, notez que cela 0.y.zest mis de côté pour une itération rapide, de sorte que le développement initial (et donc beaucoup de changements de rupture) ne vous laisse pas à quelque chose de stupide comme 142.6.0. Au lieu de remplacer la version principale, augmentez la version mineure à chaque changement de rupture jusqu'à la publication de la version 1.0.0:

La version majeure zéro (0.yz) est pour le 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 dépend entièrement de vous. Faites ce qui a du sens pour vous et soyez cohérent. Personne ne dit que vous devez partir de 0, 0,0, 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 a utilisé un système de numérotation de version idiosyncratique, où les mises à jour ont été indiquées en ajoutant un chiffre supplémentaire à la fin de la décimale, de sorte que le numéro de version s'approche asymptotiquement de π. Cela reflète le fait que TeX est désormais très stable et que seules des mises à jour mineures sont prévues. 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 versionnage similaire à celui de TeX, où le nombre s'approche asymptotiquement de e à chaque révision.

Enfin, pas tout à fait un numéro de version, mais tout aussi intéressant, c'est que l'offre publique initiale (IPO) de Google a été déposée auprès de la SEC pour avoir levé 2 718 281 828 $ (notez que e ~ 2,718 281 828).

Mon point est le suivant: 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 (numéro de version souvent augmenté => plus de $$$, les gens ne veulent pas acheter une version bêta de 0.99, etc.) doit être pris en compte. Les numéros de version «Logic» peuvent aider lorsque vous travaillez dans une grande équipe.

Et j'aime la manière linux d'avoir des nombres impairs pour les versions instables, et des nombres pairs pour les versions stables.

Lorsque je reçois ma première version utilisable mais pas une version complète, j'essaie normalement de juger à quel point elle en est à une version complète de fonctionnalités, donc par exemple, si ma première fonctionnalité utilisable est 33% de fonctionnalités complètes, je donne le numéro de version 0.3.0 ou similaire. Ensuite, à mesure que je me dirige vers la fonctionnalité, les versions correspondantes complètes reçoivent des numéros de manière similaire.

Mais une fois que vous passez à une fonctionnalité passée, la gestion complète des versions doit changer

Lorsque vous choisissez les numéros de version d'un npmpackage, sachez que pour les dépendances répertoriées dans les package.json plages de semver, ne fonctionnera pas sous la v1.0.0. C'est,

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

est équivalent à

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

Si vous voulez pouvoir utiliser des plages de semver, ou si vous voulez laisser d'autres personnes les utiliser, vous pouvez commencer avec 1.0.0

En règle générale, la gestion des versions a une certaine signification pour le programmeur. L'augmentation du nombre majeur peut indiquer des changements importants qui empêchent la rétrocompatibilité. D'autres nombres dans le numéro de version peuvent indiquer des améliorations de fonctionnalités plus petites ou des corrections de bogues.

Si vous craignez que la version 0.6.5 ait une sonnerie incomplète, vous voudrez peut-être 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 commencer à partir de 0.1.0 et de partir de là.

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 emballer que lorsqu'ils sont presque terminés (ou prêts pour les tests bêta, de toute façon). Les projets plus compliqués commencent autour de 0.1 [.0] et certains ne voient même jamais 1.0. Je considère la version 1.0 comme une version finale (ou au moins une version bêta ou une version candidate testée localement) et planifie en conséquence.

Avec les projets d'équipe, celui qui met la première balise de version décide :).

0.1.0 est ce avec quoi je commence et je monte à partir de là. C'est ce que j'ai adapté pour Xploration By Adrian, bien que 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 de partir de là.

Par Semver, réservez a et c dans abc pour A. You première version officielle et C. Correction de bugs et correctifs. En effet, une version majeure casse généralement le code plus ancien. Et les correctifs corrigent simplement les bogues. Tout cela est une préférence personnelle, 0.99.0 ne signifie pas que vous devez passer à 1.0.0, etc. J'en ai vu qui vont jusqu'à 0.218.42.

Les numéros de version devraient vous signifier comme Arrieta l'a correctement commenté auparavant.

Peut-être en suivant quelque chose comme: Le premier # est la version du maire, le deuxième # est la même version du maire avec quelques fonctionnalités ajoutées et le troisième # est la même version du maire, avec les mêmes fonctionnalités mais avec des bogues corrigés ou des changements mineurs (mais suffisamment importants) ajoutés.

1.3.2 => 1ère version, avec plus de fonctionnalités et quelques bugs corrigés.

Cependant, pour les utilisateurs finaux, certains sont habitués à de gros chiffres pour les versions finales.

Par exemple: Corel 8, pour 8.0.0, 8.0.1, 8.2.2, etc. Corel 9, pour 9.0.0 ... etc.

Et surtout, il s'agit davantage de stratégies marketing comme: Corel X5 au lieu de Corel 15.0.2 par exemple.

Je dirais que cela dépend si le numéro de version est pour vous ou pour le client.

commencez par 0.0.0 et continuez à partir de là.

Commencez avec 1.1.1 et continuez à partir de là.