Traiter des fonctionnalités qui ne figureront pas dans la version actuelle

Question

Imaginons que vous soyez actuellement à la version 3 d'un produit, et que votre prochaine version soit 4. Mais vous avez des fonctionnalités qui vont prendre beaucoup plus de temps à développer que votre cycle de publication , par exemple ne sera pas prêt jusqu'à la version 5, (pourrait être encore plus long). Quelle est la meilleure façon de gérer ce problème dans git-flow? Il me semble que ce flux de travail ne permet pas vraiment ce genre de chose. Il n'y a pas de véritable notation de la version après la prochaine version. Lorsque je travaillais, nous avions une branche pour la prochaine version, c'est-à-dire release/4 dans l'exemple ci-dessus. Et la branche maîtresse serait pour la prochaine version après la sortie/5. Les fonctionnalités qui ne seraient pas en version 4 mais en version 5 seraient développées à partir de la branche master. Les branches de sortie de release/4 seraient fusionnées en release/4 (ce qui serait une mise à jour si la version 4 avait été publiée) et ensuite master, (même si ce n'était pas un gros problème si vous oubliez de fusionner en master la prochaine personne si elle se souvenait le ferait pour vous.)

Lorsque nous passions à la prochaine version, nous dérivions à nouveau le maître, c.-à-d. créer une branche release/5. Les caractéristiques à être dans release/5 auraient dérivé de release/5, tout ce qui doit être fait dans release/6 serait sur le master, et ainsi de suite.

J'ai bien aimé ce flux de travail pour ce scénario, car il facilitait le développement de fonctionnalités gourmandes en temps, tout en ayant l'intention de prendre en compte les versions. Je suis intéressé par les stratégies comment cela peut être réalisé en utilisant des modifications de git-flow?

Answer 1

Si vous le pouvez, vous pouvez envisager un "workflow git" au lieu de gitflow.
Je vous présente dans « Handle git branching for test and production »

L'idée est d'avoir des branches éphémères « next » (un pour v4, v5 un ou plus tard), que vous recréez après chaque sortie.

En eux, vous fusionnez vos branches feature que vous voulez. Mais si ces branches feature sont prêtes pour le prochain release, vous ne fusionnez pas la branche 'next' à release (comme vous le faites dans gitflow lors de la fusion develop à release). Vous fusionnez la branche feature elle-même à release.

De cette façon, vous pouvez gérer le cycle de vie de ces fonctionnalités à long terme comme vous le souhaitez, et les valider dans l'intégration avec ohter dans la branche appropriée (v4, v5, ...) de votre choix.