The current development model of HourGlass is not that great.
Small to implement fixes (maybe even important ones like ones fixing crashes) may not appear in public builds quickly, as I might have been entangled in developing complicated experimental new features.
I’ve been using Git to track HourGlass source code for about 2 years now, but not really got too advanced with it by using branches and merging. I am now going to learn that stuff. This would be interesting for the end users of the software as I could then probably start releasing “best effort to work” and “experimental madness” versions in parallel. Then, when the madness has settled in the experimental versions, the good changes could be merged into the “best effort to work” version. At the same time, minor fixes could be incorporated into the “best effort to work” version and released as needed.
Let’s see how it goes…I try to get the 1.1.1 (or maybe it’s worth 1.2.0) version out before the end of the week and then I can look into the new releases model.
Great! waiting for the next release.
Its a great tool!