reaperrr
I'd clearly prefer smaller but more frequent releases. I also agree that issues that have the same 'topic' should be concentrated on one release instead of being spread over several releases. For example like Ren said, I think it would make sense for #846, #882 (both currently scheduled for 0.2) and the sub-issues of #173 (currently scheduled for 0.3) to be in the same release as they all revolve around the RMG.
Btw, this is just a suggestion (and I guess something like this would happen anyway, even without me suggesting it
), but I think after DFD is finished the roadmap could use some revising either way.
It's just my personal opinion, but I believe it would make sense to move features that are both very popular and require only a moderate or even relatively low amount of programming to the earliest possible release(s), and push stuff that is very complex and/or has very little community-backing back to later releases.
Time is a limited resource as we all know, and who knows, maybe YR won't even run on Microsoft's next OS, so I really think the "most wanted" features that aren't too problematic to implement should be given the highest priority, followed by the "possible and wanted but a bit complicated" stuff and finally the "rather simple but not that popular/interesting" stuff should be last (because if barely anyone is going to use it, there's no point in doing it early, imo).
Btw, this is just a suggestion (and I guess something like this would happen anyway, even without me suggesting it
), but I think after DFD is finished the roadmap could use some revising either way. It's just my personal opinion, but I believe it would make sense to move features that are both very popular and require only a moderate or even relatively low amount of programming to the earliest possible release(s), and push stuff that is very complex and/or has very little community-backing back to later releases.
Time is a limited resource as we all know, and who knows, maybe YR won't even run on Microsoft's next OS, so I really think the "most wanted" features that aren't too problematic to implement should be given the highest priority, followed by the "possible and wanted but a bit complicated" stuff and finally the "rather simple but not that popular/interesting" stuff should be last (because if barely anyone is going to use it, there's no point in doing it early, imo).