So far it’s mostly been a bit of “whenever I have time for it” and a bit of “whenever someone asks for it”, which lately has both been “not very often”.
I used to also do a lot of testing before releasing a new version, to make sure everything was 100% in order and working as documented. This also means checking if there are any open issues, making sure all contributions have been of high enough quality, and fixing things where needed. I’d say more than half the patches submitted need some work from me afterwards, partly because I’m very picky about whitespace in the generated code
This pre-release testing and checkup is by far the most labor intensive part of maintaining Chestnut. I’ve been doing less of it for recent releases, assuming that it’s pretty stable now and people will tell me when it breaks, but as the Procfile example shows, that might be a feedback loop that’s too slow.
I was also stalling a bit with the current release because I wanted to address documentation first. Chestnut does not nearly have the level of documentation that I’d like it to have, and rarely gets contributions in the form of documentation, so I’m going to have to stake out a couple of days to fix that. The earliest I can imagine finding those days is at the end of the year around Christmas/New Years.
Snapshot builds are a different story, people need to opt in to these, and so occasional breakage should be expected. If we can easily automate master->SNAPSHOT releases then I’m all for it.