On 2/6/23 23:07, Christof Ressi wrote:
Afterwards, maybe current development can be in the branch until ready, ie. feature/multi-channel or develop/0.54, etc?
That's what I would suggest in general.
It would be great if all new features, rewrites, experiments, etc. could be made in feature branches. This has several advantages:
- When working in a feature branch, you can mess around without
worries. In the worst case, you can just roll back and force push. Also, it allows to squash the commits before merging for a nicer commit history (= less intermediate commits)
- We can merge the develop branch into master any time and make bugfix
releases while simulatanouesly working on new features.
- The master branch would always be stable.
i think this sounds a bit like over-engineering in our case. we almost have this scheme.
1. just name your branches "bugfix/clone-mc" and "feature/tasks". 2. we can already merge the "develop" branch into "master" any time 3. the "master" branch is mostly stable (untouched) anyhow.
btw, a "develop/0.54" sounds impractical, as it is not clear how that would be different from a "develop/0.55" branch. (apart from the very simple (and trivial to solve) caveat, that currently `develop` is already a branch name, which occupies the entire 'develop/' namespace)
afaict most branching strategies are not tailored towards the development model that Pd currently uses (a bdfl with short bursts of activity interrupted by longish breaks; a limited number of contributors who create their bugfix resp. feature branches).
there is probably room to improve the current development model, but the branching strategy should follow the development model rather than the other way around. (that is: if you want to change the development model, feel free to discuss it. but i think it would be better to do this first)
mgfdsr IOhannes