hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: About fix versions
Date Sun, 29 May 2016 12:16:04 GMT
Thanks Allen a lot. This is comprehensive. 

>> So if a patch has been committed to branch-2.8, branch-2, and trunk, then the fix
version should be 2.8.0 and only 2.8.0.  
This sounds like the right rule I seem to need and want to know, but guess it may change around
the 3.0 release.

Regards,
Kai

-----Original Message-----
From: Allen Wittenauer [mailto:allenwittenauer@yahoo.com] 
Sent: Sunday, May 29, 2016 12:17 PM
To: Zheng, Kai <kai.zheng@intel.com>
Cc: common-dev@hadoop.apache.org
Subject: Re: About fix versions


> On May 28, 2016, at 5:13 PM, Zheng, Kai <kai.zheng@intel.com> wrote:
> 
> Hi,
> 
> This may be a stupid question but I want to make sure. What fix versions would we fill
with when a committer just wants to commit a patch to trunk or branch-2 branch?

	This is covered on the https://wiki.apache.org/hadoop/HowToCommit page:

== snip ==
Resolve the issue as fixed, thanking the contributor. Always set the "Fix Version" at this
point, but please only set a single fix version, the earliest release in which the change
will appear. Special case- when committing to a non-mainline branch (such as branch-0.22 or
branch-0.23 ATM), please set fix-version to either 2.x.x or 3.x.x appropriately too.
== snip ==

	So if a patch has been committed to branch-2.8, branch-2, and trunk, then the fix version
should be 2.8.0 and only 2.8.0.  

	Bear in mind that this field determines what changes appear in the changelog and release
notes.  If this field is filled out incorrectly, then this commit will effectively be missing
for end users or appear in the wrong version as ‘new’.

>  I remembered it's a release manager's role to decide which jira/patch to include when
working on a release. Would anyone help clarify a bit about this, thanks!

	This is when cutting the release and has no bearing on what committers should be putting
in JIRA.  If an RM decides that a commit shouldn’t be in a release, they are responsible
for reverting the commit and changing the fix version to whatever is appropriate.
Mime
View raw message