Forké un projet, où commencent mes numéros de version?

12

J'ai bifurqué un projet et j'en ai changé beaucoup. Cette fourchette n'est pas seulement un petit changement de fonctionnalité ici et une correction de bogue enfouie là, c'est un changement assez substantiel. Seule la majeure partie du code principal est partagée.

J'ai bifurqué ce projet en v2.5.0. Pendant un certain temps, j'ai commencé à versionner ma fourche à la v3.0. Cependant, je ne sais pas si c'est la bonne façon, principalement parce que lorsque ce projet arrive en v3.0, les choses deviennent confuses. Mais je ne veux pas recommencer à la v1.0 ou à la v0.1 car cela implique la petite enfance, l'instabilité et la non-réflexion d'un projet. Ce n'est pas vrai, car la plupart du code de base est très raffiné et stable.

Je ne sais vraiment pas quoi faire, alors je demande ici: Quelle est la façon standard de gérer ce genre de situation? La plupart des fourches recommencent-elles, augmentent-elles les numéros de version ou font-elles autre chose que je ne connais pas?

versioning

— TheLQ
source

5

Je ne vois pas comment 1.0 implique l'enfance ou l'instabilité. Tout ce qui est en dessous de 1.0 oui, mais 1.0 implique qu'il est hors de la période `` infantile '' et prêt à basculer. Si cela vous rend plus à l'aise,

— optez

1

Par curiosité, qu'avez-vous fourchu?

— compman

13

La plupart des fourches que j'ai vues recommencer à partir de la version 1.0. Mais je suppose que vous avez également changé le nom de votre fork, donc je ne sais pas pourquoi il y aurait confusion si vous commenciez simplement à partir de la v3.0.

Ce que je ferais, c'est changer le nom du projet, publier la version 1.0 et préciser que le projet est un fork d'un autre projet. Je ne pense pas qu'il y aura de confusion avec cette approche.

Si vous êtes vraiment inquiet au sujet du label "1.0", sortez simplement la version 2.0 peu de temps après 1.0 ...

— Dean Harding
source

... ou libérez directement la v2.0, sans passer par la v1.0. Ce ne serait pas la première fois que cela se fait.

— Konamiman

Dans mon entreprise, un projet a même commencé en v2.4.

— user253751

6

Ayez votre propre feuille de route et respectez-la, en commençant par le numéro de la version d'origine, mais n'essayez pas de courir avec la version actuelle du produit d'origine.

— dukeofgaming
source

1

Si vous n'essayez pas de mettre en parallèle le projet d'origine d'une manière ou d'une autre, il n'y aura pas de corrélation significative entre les numéros de version à l'avenir. Cela signifie qu'il est inutile d'essayer d'établir une telle corrélation maintenant - en commençant à 3.0 - car cela ne fera qu'établir une attente irréalisable.

— Tom Anderson

Je me suis trompé. Vous devriez commencer votre propre v1.0, qui vous aidera à vous différencier. Les versions devraient signifier quelque chose, pas seulement un coup de marketing (v.gr. "v5.4" pour ne pas avoir l'air neuf).

— dukeofgaming

1

@ TomAnderson: S'il opte pour, disons, la version 2.5 et crée la première version de sa fourchette 2.6 ou 3.0, il peut pointer vers l'autre application comme l'historique complet de son projet. Ce qui est une corrélation modestement significative.

— DougM

3

Vous voudrez peut-être déterminer si (et dans quelle mesure) votre projet sera lié au projet d'origine. Si vous prévoyez de porter de nouvelles fonctionnalités du projet d'origine dans votre, vous pouvez envisager de conserver vos numéros de version correspondant aux versions de l'original.

À titre d'exemple, consultez MariaDB, qui est un fork de MySQL. Ils veulent le garder comme un remplacement «drop-in» pour MySQL, donc par exemple MariaDB 5.2 a toutes les fonctionnalités de MySQL 5.2.

Voir: http://kb.askmonty.org/v/mariadb-versus-mysql

Remarque: Depuis que cette réponse a été publiée, MariaDB a considérablement divergé de MySQL et suit maintenant son propre schéma de version.

— Mchl
source

1

0,1 peut indiquer la petite enfance, mais la version 1.0+ signifie stable. Une augmentation des numéros de version majeurs, par exemple 2.0, 3.0, indique généralement un changement important de fonctionnalité.

Par exemple

La version 1.0 de mon application était un outil pour exécuter des scripts de test avec la configuration,
La version 2.0 a supprimé la différenciation entre les scripts de test et les scripts de configuration de l'environnement,
La version 3.0 a ajouté une interface graphique pour l'écriture de scripts sous forme de diagrammes de flux. Ce sont des produits clairement différents, mais même la version 1 était un produit fonctionnel, complètement stable, etc. Les versions 2 et 3 ont vu le jour car il a été décidé que ces grands changements seraient bons. Si nous n'avions pas voulu ces grands changements, et que nous avions juste continué à faire des corrections de bugs, etc. Les numéros de version mineurs auraient juste augmenté, 1.10,1.20, etc.

Ce que je dis, c'est que les numéros de version majeurs n'indiquent pas la maturité, ils indiquent les principaux ensembles de fonctionnalités. Maintenant, c'était un peu une tangente de la façon de numéroter la version de votre produit.

Ce que j'ai vu auparavant, ce que j'aimais bien, c'était de recommencer la version à partir de 1.0 (ou de 3.0 si vous préférez vraiment), puis entre parenthèses indiquant de quelle version de l'original il comportait la dernière fois des fonctionnalités.

Initialement: " MyFork v1.1 (basé sur OrigProg v3.0)
Quelques améliorations apportées à MyFork: MyFork v1.3 (basé sur OrigProg v3.0)
OrigProg a publié une version majeure et MyFork a tiré et fusionné: MyFork v2.1 (basé sur OrigProg v4.0)
Apporté des modifications majeures à MyFork (ne sera probablement plus jamais en mesure de fusionner facilement avec OrigProg): MyFork v3.0 (basé sur OrigProg v4.0)

— Lyndon White
source

0

Si possible, fusionnez votre fork avec le projet d'origine. Je ne saurais trop insister sur ce point.

Reprenez vos numéros de version, puis utilisez celui à partir duquel vous avez croisé plus un suffixe de date.

2

Le passage de "Python 1.1" à "Userthon 1.1. {DATE}" rompt le format attendu des numéros de version.

— DougM