[PD-dev] branch names (was Re: figuring out how to get everything merged)

[Christof Ressi]

> 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 at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev