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 > > > > > > > > > >
