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
<por...@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$>
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/K2UUWV4E4E2CSXVSJWMN7WADCFZZYTNZ/
