I'm fine with branching master, (hard) resetting back to a previous point, merging/cherry-picking portaudio fixes, tagging 0.53-2, then doing a force push. As long as everyone knows ahead of time, we can do a force pull afterwards. Yes, it's best avoided, but is sometimes be needed.
Afterwards, maybe current development can be in the branch until ready, ie. feature/multi-channel or develop/0.54, etc?
On Feb 6, 2023, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Mon, 6 Feb 2023 09:44:36 +0100 From: IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: [PD-dev] branch names (was Re: figuring out how to get everything merged) Message-ID: <47a595e9-4e0a-12fb-1432-41803fc6c8a8@iem.at mailto:47a595e9-4e0a-12fb-1432-41803fc6c8a8@iem.at> Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 2/5/23 22:37, Miller Puckette via Pd-dev wrote:
Yep, I originally made a "0.53" branch but then messed it up so badly I had to start over - and thought it better to change the name to avoid confusion.
i see. it seems like the "avoid confusion" did not utterly succeed though ;-)
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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.
Christof
On 06.02.2023 21:50, Dan Wilcox wrote:
I'm fine with branching master, (hard) resetting back to a previous point, merging/cherry-picking portaudio fixes, tagging 0.53-2, then doing a force push. As long as everyone knows ahead of time, we can do a force pull afterwards. Yes, it's best avoided, but is sometimes be needed.
Afterwards, maybe current development can be in the branch until ready, ie. feature/multi-channel or develop/0.54, etc?
On Feb 6, 2023, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Mon, 6 Feb 2023 09:44:36 +0100 From: IOhannes m zmoelnig zmoelnig@iem.at To:pd-dev@lists.iem.at Subject: [PD-dev] branch names (was Re: figuring out how to get everything merged) Message-ID: 47a595e9-4e0a-12fb-1432-41803fc6c8a8@iem.at Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 2/5/23 22:37, Miller Puckette via Pd-dev wrote:
Yep, I originally made a "0.53" branch but then messed it up so badly I had to start over - and thought it better to change the name to avoid confusion.
i see. it seems like the "avoid confusion" did not utterly succeed though ;-)
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
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:
- 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.
- just name your branches "bugfix/clone-mc" and "feature/tasks".
- we can already merge the "develop" branch into "master" any time
- 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
-
Christof Ressi -
Dan Wilcox -
IOhannes m zmölnig