Hi Flex team, Reviewing your activities to try and help this community run in a smoother way, I'm wondering why you need release candidates.
Those were useful during your Apache incubation, to allow "total strangers" who don't have the right tools for example to review your releases, but in a small team that does have the appropriate tools to verify things form source I'm not sure they are worth the effort. Release candidates create a lot of work for the release manager, and require a lot of coordination between yourselves to find out when to create another one, cast multiple votes or argue about when it's appropriate to carry votes over, etc. Based on other projects, I'm suggesting a simpler way of creating your releases, below. As usual, this is only my old fart^H^H^H^H experienced Apache member advice, feel free to take it into account or not. You might also just try it on one of your releases to see if it works - it's easy to try. -Bertrand Here's my suggested release (non-) process: Designate a Git branch to become the release and create a jira version number that represents it. Create small, specific jira issues for things (including integrating patches from other branches) that prevent the branch from being released as is, and link those to the release version in jira, so that simple jira queries show what’s left to do and what's been done. Setup your continuous integration system to run regularly on that branch, ideally after every commit. Ask people to review the branch and create jira issues for anything wrong with it. Wait until all jira issues are closed (or rescheduled), prepare the release artifacts, vote on them and release. You vote just once, you’re not arguing all the time about where the release stands (or if you do that’s in or about specific jira issue which make things clearer), and the release vote passes 99% of the time.
