Sounds right. May need to change when there are releases on multiple branches pending.
On Fri, Feb 6, 2015 at 1:07 PM, Jacques Nadeau <[email protected]> wrote: > +1 > > On Fri, Feb 6, 2015 at 11:50 AM, Julian Hyde <[email protected]> wrote: > > > I have been using the following process for marking issues fixed/closed. > > > > * When a committer commits a patch to apache master, they must mark the > > case fixed, set its fix version to the upcoming release, and add a > comment > > “Fixed in <commit URL including hash>” to the case. > > * When the release is made, the release manager finds all issues marked > > fixed with that release and closes them (see > > > > > https://github.com/apache/incubator-calcite/blob/master/doc/HOWTO.md#making-a-release-for-calcite-committers > > ) > > > > As the release manager, I am currently doing the latter task, and I > found a > > few issues marked “fixed” without fix version. I am manually setting fix > > version now. > > > > Also, as we recently discussed on this list, committers can set the fix > > version of open issues to “next”. This indicates the intention to fix > these > > issues in the next release, but it is not a commitment. If you are not a > > committer, you must never set the fix version (even if jira allows you > to). > > You can vote for the issue or (the best vote of all!) contribute a patch. > > > > OK with everyone? > > > > Julian > > >
