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