Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0 features onto 0.4.1?
On Thu, Dec 17, 2015 at 6:38 PM, Oleg Zhurakousky < ozhurakou...@hortonworks.com> wrote: > I think we want to exclude new features and make it a true maintenance > release, so only bugs should go into 0.4.1 > > > On Dec 17, 2015, at 6:17 PM, Matt Gilman <matt.c.gil...@gmail.com> > 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 <b...@cloudera.com> 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. > >> > >
