I will just go ahead an admit that I am bad at pushing the releases and keeping a roadmap on track.
What usually happens is that we agree on some features/bugfixes that should make it into the next release. Then new bugs emerge and new fixes, and then I delay the release to get those into the next version, and we end up not having a new release.
Since the releases are signed with a certificate that is my personal one, I need to do the actual builds, and I will happily do so.
But we need someone who decides which fixes go into what version, and which issues are blocking a release. Alternatively we can do it with a fixed scheme, say a beta each 3 months, but I think that is more likely to break things.
I can give you commit access to the github repo. From there I think it is a matter of creating a branch (say releases/experimental_v2.xxxx), base it on some relatively safe point, and maybe cherry pick commits into that.
Once you are happy with the version, maybe we should start a topic in #releases and people can chime in with opinions (in case there is something that really should not go out).
Then I will be the “build-bot” and press the button once we have a “go”.
For a more planned approach, @kees-z made a great job collecting a number of issues that we should fix: 2.0 stable Milestone · GitHub
I think the milestone approach is the right way to plan and discuss releases, but I have been tied up (too much) on the concurrency branch, because it will also greatly improve code readability and make it simpler to introduce a number of larger changes that I have planned.
It looks like I have managed to get it working, but Travis is having some issues, so I cannot verify that it actually works.