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