One small issue is that I see a number of JIRAs that are marked with a fixVersion of 4.7.0 but have not yet been fixed. We typically only set the fixVersion when a fix has been committed. I'll go through these are clear this field out for unresolved issues.
Thanks, James On Fri, Nov 20, 2015 at 6:32 PM, Enis Söztutar <[email protected]> wrote: > James, that makes sense, opened > https://issues.apache.org/jira/browse/PHOENIX-2442 for that. > > I also closed all issues matching this filter (881 in total): > project = PHOENIX AND fixVersion in releasedVersions() and status in > (resolved,closed) order by fixVersion DESC > > Enis > > > On Fri, Nov 20, 2015 at 5:42 PM, James Taylor <[email protected]> > wrote: > > > Thanks so much, Enis. These are super helpful. Do you think we should add > > these best practices to our "How to do a release" page? [1] > > > > James > > > > [1] http://phoenix.apache.org/release.html > > > > On Fri, Nov 20, 2015 at 5:39 PM, Enis Söztutar <[email protected]> wrote: > > > > > Thanks guys, > > > > > > I did these changes: > > > - Renamed X.Y -> X.Y.0 > > > - Renamed X.Y-Release -> X.Y.0 > > > - Created 4.6.1 > > > - Released most of the versions in jira. The current unreleased ones > > should > > > correspond to reality (as much as I can tell). It would be good if > > somebody > > > can verify. > > > > > > > > > https://issues.apache.org/jira/plugins/servlet/project-config/PHOENIX/versions > > > . > > > - Did not add release dates to jira. It maybe helpful. > > > - Created https://issues.apache.org/jira/browse/INFRA-10817 for the > > > workflow change. > > > > > > A couple of suggestions we can follow in Phoenix (from best practices > in > > > HBase and Hadoop community): > > > - Committers should be careful and always mark correct fixVersions > when > > an > > > issue is committed. The fixVersion should contain the next scheduled > > > release from branches that the fix is committed. This one is pretty > > > important, since it is the only way to cleanly see what issues 4.6.1 > > > contains over 4.6.0 for example. > > > - Always make sure that issues are resolved after commit. > > > - The release manager should make sure that > > > -- All issues in that release have a jira with correct fixVersion. > > > -- Make sure that all jiras with fixVersion=X.Y.Z is either resolved > or > > > moved out of the release before cutting the RC. > > > -- Create X.Y.Z+1 as a release version in jira > > > -- After the release, do a double check that no new issue is marked > > with > > > fixVersion=X.Y.Z (since it was not in the release). > > > -- After the release, close all the jiras. For doing that, do a jira > > > search like this: > > > > > > project = PHOENIX AND fixVersion = X.Y.Z ORDER BY priority DESC > > > Tools -> Bulk change -> Transition issues -> close > > > comment: Closing this issue after 1.0.2 release. > > > uncheck send mail > > > > > > > > > Happy Friday, > > > Enis > > > > > > > > > On Fri, Nov 20, 2015 at 4:18 PM, Nick Dimiduk <[email protected]> > > wrote: > > > > > > > Lgtm > > > > > > > > On Friday, November 20, 2015, Enis Söztutar <[email protected]> wrote: > > > > > > > > > Hi, > > > > > > > > > > It seems that we need some cleaning in the jira. I can do these > > changes > > > > if > > > > > it is ok with everyone. > > > > > > > > > > 1. Versions with typos are there (4.60, etc). Jira will auto-create > > > these > > > > > release versions if one types it in fixVersions. I'll remove these. > > > > > > > > > > 2. 4.6.0 is released, but not released in Apache. We should > "release" > > > > that > > > > > version in jira so that future issues cannot be tagged with that > > > release > > > > > version. We (in HBase) documented that to be a part of the release > > > > > management process. Looking at > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/plugins/servlet/project-config/PHOENIX/versions > > > > > > > > > > I don't see any versions that is "released" in jira. I think we > > should > > > > mark > > > > > every version as released that corresponds to an actual release. > > > > > > > > > > 3. Best practice is to close all the jiras in the release, so that > > they > > > > > cannot be reopened and changed. > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/PHOENIX-2244?jql=project%20%3D%20PHOENIX%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%204.6.0%20ORDER%20BY%20priority%20DESC > > > > > > > > > > 4. jira Workflow: change it to "no-reopen-closed". This workflow is > > > > safer, > > > > > and used in HBase and Hadoop. The jiras in closed state cannot be > > > > > re-opened. if we make sure to close all the jiras after a release, > > the > > > > list > > > > > of jiras committed and marked for that fixVersion becomes final. > If a > > > > patch > > > > > for the jira is released in a version, then only creating a new > jira > > > will > > > > > be the way to change. This makes issue and patch tracking for > > releases > > > > > easier I think. > > > > > > > > > > Let me know whether these makes sense or not. > > > > > > > > > > Enis > > > > > > > > > > > > > > >
