I’m evaluating hgflow. The model meets most of my version control needs except that I can’t figure out how to support multiple releases.
Assuming I have released v1.0 a while ago, have just released v2.0 and I have been using hgflow since the beginning. A customer who is still on v1.0 requests for a feature to be implemented. Because of the stability of v1.0, he doesn’t want to upgrade to v2.0 or v3.0.
Using the generalized streams concept:
- hg flow develop start 1.x (create develop/1.x)
- hg flow develop/1.x:release start 1.0 (create release/1.0 from develop/1.x)
- hg flow develop/1.x:release finish (close release/1.0 and create v1.0 on master)
- repeat for 2.x & 2.0, so v2.0 tag is created on master after v1.0 tag
- request to enhance 1.x is received
- hg flow develop/1.x
- work on enhancement
- hg flow develop/1.x:release start 1.1 (create release/1.1 from develop/1.x)
- hg flow develop/1.x:release finish <— v1.1 tag is created after v2.0 tag on master
If I follow the hgflow model, I may end up with a v1.1 tag created after the v2.0 tag in the master stream. Worse still, the changes in v1.1 may overwrite the various enhancements I have made between v1.0 to v2.0.
My question is: can anyone suggest a solution to my problem? Any suggestion is appreciated. Thanks.
The workflow that you want to use for this situation has something to do with the support stream:
All your changes to support the 1.x release are in the support/1.x branch, which by concept will normally not merge to other streams.