On that topic... I'm pretty careful about bugfix releases - I don't even try to fix bugs that don't look like show-stoppers, because I've sometimes created deeper, more subtle bugs in trying to fix obvious ones :) All that typically goes into 'master' so that it will make it in the next version (now 0.56).
In the past I've always identified master with the very-latest-maybe-buggy code, since that's the code I myself use in concerts. The advantage is that it forces me to keep things working most of the time... the disadvantage is that it makes me reluctant to embark on major changes like the one I'm working on now on data structures.
If it makes life easier for everyone else I could switch to a merge-into-master mode in which there's a rawhide branch that I'm personally using. But this might create more work since, if other PRs are getting merged into master, I'll also have to merge them into rawhide. I'm not sure what the best strategy would be.
Incidentally I'm planning to break my own rule to update 0.55 to be compatible with externs that use pd_class_new() so that people can compile externs that work both in 0.55 and in VSTs. That's more a compatibility enhancement than a bug fix. Other than that I don't have any changes planned for 0.55 - I'm focussed on 0.56 .
cheers Miller
On 4/5/25 2:46 PM, Dan Wilcox wrote:
This is probably a diff but related topic:
I think we as a group really need to calm down on the "let's jam features in NOW" cycle. There should at least be a list made of what things are ready/important, perhaps in a Github issue, then we can clearly take a look at what makes sense to put into a possible BUGFIX 0.55.4 release and a larger 0.56 release (which IMO should have new features).
It's just not sustainable to keep adding new, possibly breaking stuff into bugfix release. I think the development model should really move to a develop branch which merges *changes / new stuff* and the master branch keeps bug fixes only. Newer features should also have enough time to be solidified in discussion and testing, although I realize most people (myself included) can't work on things all the time but in certain periods.
On Apr 5, 2025, at 1:20 PM, Alexandre Torres Porres porres@gmail.com wrote:
That makes sense, and we already have some new features, like 'start or stop subprocess gui', new format specifiers for [makefilename] (%a/%A/%F), and some stuff for data structures I couldn't try and get yet. Maybe there's some more I don't know/remember, and I bet there are some lower hanging fruit to easily jam in a couple or more features (the 1-byte audio support you worked on comes to mind).
Dan Wilcox danomatika.com https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!EiVHWwjVG7aUiFOWzq4zet0CSLg3BsWZgwtrv7-dSzf7Zfguw6HrtzJ2BMZO1cCBbgWTYhBDPs_EBtc$ robotcowboy.com https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!EiVHWwjVG7aUiFOWzq4zet0CSLg3BsWZgwtrv7-dSzf7Zfguw6HrtzJ2BMZO1cCBbgWTYhBD9xYKCIU$