I see, that does appear to be the case. What your suggesting sounds good. Though we should review the tickets that addressed UI bugs/improvements. I realize you probably specifically just chose the JIRAs that addressed bugs. I'd want to make sure that the tickets included don't have a dependency on the tickets excluded. For instance, merge conflicts because a commit in an included ticket is based off the code base after a commit in an excluded ticket.
Matt On Thu, Dec 17, 2015 at 6:17 PM, Matt Gilman <[email protected]> wrote: > Are there some commits on master that we don't want included in 0.4.1? If > not, wouldn't we just follow our normal release process? > > Matt > > > On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue <[email protected]> wrote: > >> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking >> makes sense to me. >> >> rb >> >> >> On 12/17/2015 12:29 PM, Joe Witt wrote: >> >>> team, >>> >>> matt clarke just discovered an interesting case that appears to expose >>> a defect in site-to-site. The details of it are still being worked >>> out as you can see in NIFI-1301. And this issue has been around for a >>> very long time but it still feels like something worth addressing in >>> an incremental/bug release (0.4.1). >>> >>> I looked at already addressed bugs on 050 and added the to fix >>> versions of 041 as well. What I am wondering here is a bit of a >>> proper usage and thinking with Git. Would it make sense to branch off >>> master right where 0.4.1-SNAPSHOT started, then cherry pick the >>> commits into this new branch, and just release that branch never >>> needing then to merge that back to master since these fixes are all >>> already on master anyway? >>> >>> >>> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC >>> >>> Thanks >>> Joe >>> >>> >> >> -- >> Ryan Blue >> Software Engineer >> Cloudera, Inc. >> > >
