i think this sounds a bit like over-engineering in our case.
Where do you see over-engineering?
we almost have this scheme.
Maybe I was a bit too vague. Of course, contributors like you and me
already do this. I was rather suggesting that Miller himself would also
use feature branches instead of pushing directly to master.
But this is just a suggestion. I just think that it could help avoid
tricky situations like this in the future.
Christof
On 06.02.2023 23:47, IOhannes m zmölnig wrote:
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:
1. 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)
2. We can merge the develop branch into master any time and make
bugfix releases while simulatanouesly working on new features.
3. 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
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
