I'll take release manager duties for 0.7.0 unless someone else with committer status really wants to give it a go.
Right now there are 43 tickets assigned to it. I'll go through and punt ones on there that seem stalled or deferrable. Of course, if there are any that are particularly important to something you might need please do comment to that effect. As we close down on number of 0.7 tickets I'll kick off the proceedings. https://issues.apache.org/jira/browse/NIFI/fixforversion/12335078 Thanks Joe On Tue, May 31, 2016 at 10:00 PM, Ryan H <rhendrickson.w...@gmail.com> wrote: > Also looking forward to using the TransformJSON processor: > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java > > Nice choice with JOLT there. > > We're doing a custom one for jolt transformers for that now. > > Ryan > > On Fri, May 27, 2016 at 11:21 AM, Ryan H <rhendrickson.w...@gmail.com> > wrote: > >> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with the >> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521) >> >> Thanks! >> >> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <joe.w...@gmail.com> wrote: >> >>> Ok just to wrap up this thread. Will push a couple efforts >>> 1) Will start pulling together an 0.7 release >>> 2) Will update the roadmap slide to put in tentative timing/major >>> elements in the roadmap on the wiki page >>> >>> And as for whether 0.7 ends up being the last release of the 0.x line >>> will just depend on 1.0 release timing and community interest in doing >>> an 0.8. We don't have to decide that now. >>> >>> Thanks >>> Joe >>> >>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <alopre...@apache.org> >>> wrote: >>> > I think Mike’s read on the published guidelines is correct, but I agree >>> with >>> > Joe that if we release 0.7 two weeks before 1.0, feature development >>> that is >>> > merged after 0.7 does not need to be backported. Maybe this is >>> something we >>> > should clarify on the wiki once we reach a consensus. >>> > >>> > >>> > Andy LoPresto >>> > alopre...@apache.org >>> > alopresto.apa...@gmail.com >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>> > >>> > On May 17, 2016, at 3:43 PM, Joe Witt <joe.w...@gmail.com> wrote: >>> > >>> > Mike >>> > >>> > I agree with the letter of the reading so this thread is to discuss >>> > the spirit of it and how to best apply it to our situation and >>> > community now. Whether it is 'just before' or 'just after' or 'same >>> > time' I think it is within the intent. I just want us to be clear >>> > what it is. It is extra work to ensure each PR is applied to both >>> > lines and extra work increases contributor and reviewer burden so we >>> > should be mindful of that as it is a dragging force. We also need to >>> > keep in mind that with 1.x we have Java 8 as a minimum and so there >>> > are cases which will not apply to both and we don't want folks to >>> > avoid using Java 8 features just so it can apply to both. >>> > >>> > My preference is that we have 0.7 as the last planned feature release >>> > in 0.x and with that in mind we need to choose to have it be a bit >>> > before, a bit after, or at the same time as the 1.x release. I >>> > personally am comfortable with what I proposed for 0.7 vs 1.0 timing >>> > but I am fine if the consensus is to release the last 0.x and 1.0 at >>> > the same time. Just hoping to avoid needing to have another feature >>> > release on 0.x after 0.7 other than some special request that might >>> > come up later (which is also discussed in the support doc). >>> > >>> > I also agree the release process for 1.0 will be significant as it >>> > will include important new features. Definitely need folks testing >>> > out and providing feedback on the features early and often. >>> > >>> > Thanks >>> > Joe >>> > >>> > On Tue, May 17, 2016 at 6:20 PM, Michael Moser <moser...@gmail.com> >>> wrote: >>> > >>> > The way I read the release support document, I don't think the feature >>> > cut-off for the 0.x branch happens when we confirm a release date for >>> 1.0, >>> > I think it occurs once we actually release 1.0. Maybe the cut-off can >>> > happen once we declare the first 1.0 release candidate. I'm sure we >>> will >>> > spend significant time doing testing and bug fixes on 1.0 release >>> > candidates. If I recall, we spent 2 weeks on 0.6.1 release candidates. >>> > >>> > -- Mike >>> > >>> > >>> > On Tue, May 17, 2016 at 6:04 PM, Joe Witt <joe.w...@gmail.com> wrote: >>> > >>> > I believe that is right Andy. The support guide articulates that we >>> > could do a feature release upon request if there was some specific >>> > need a community member had but that otherwise the only releases on an >>> > older line still supported would be focused on security/data loss type >>> > items. >>> > >>> > Thanks >>> > Joe >>> > >>> > On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <alopre...@apache.org> >>> > wrote: >>> > >>> > This schedule seems appropriate to me. Once 0.7.0 is released and we >>> > >>> > confirm >>> > >>> > the release date for 1.0, feature development is completely targeted to >>> > >>> > 1.0, >>> > >>> > correct? Security and data loss bug fixes would still be backported, but >>> > >>> > new >>> > >>> > features would not. >>> > >>> > Andy LoPresto >>> > alopre...@apache.org >>> > alopresto.apa...@gmail.com >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>> > >>> > On May 17, 2016, at 1:19 PM, Joe Witt <joe.w...@gmail.com> wrote: >>> > >>> > Ok - i'm good with an 0.7 release too and think it is a good idea. I >>> > am happy to RM the release. >>> > >>> > I'd like to select a date at which we're happy to call the 0.x line >>> > then feature complete which means 0.7 would be the last feature >>> > bearing 0.x release and from then on it would be bug fixes only >>> > consistent withe support model. To do that I think we should feel >>> > reasonably confident that the 1.x release is close. So let's say we >>> > did an 0.7 release early June - say first week of June. I'd like us >>> > to say then that 1.x is targeted to early July. >>> > >>> > If this seems like a reasonable path I'll start filling out the >>> > tragically never updated roadmap wiki page [1] with the 0.7 target, >>> > 1.x target, and put some placeholder/tentatives for the 1.1 and beyond >>> > targets. Will wait for additional inputs. >>> > >>> > [1] >>> > >>> > >>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850 >>> > >>> > >>> > Thanks >>> > Joe >>> > >>> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky >>> > <ozhurakou...@hortonworks.com> wrote: >>> > >>> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of >>> > improvements and new features/components in it already, and would like >>> to >>> > give it some miles before 1.0. >>> > >>> > Oleg >>> > >>> > On May 17, 2016, at 4:02 PM, James Wing <jvw...@gmail.com> wrote: >>> > >>> > I'm definitely in favor of releasing 0.7.0, but I don't think we need be >>> > rigid about the schedule. If delaying 0.7.0 a few weeks (2-4?) helps >>> > >>> > pace >>> > >>> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me. >>> Do >>> > we believe that is still a likely target? >>> > >>> > Thanks, >>> > >>> > James >>> > >>> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <joew...@apache.org> wrote: >>> > >>> > Team, >>> > >>> > Want to start zeroing in on the details of the next releases. We had >>> > a good set of discussions around this back in January and have since >>> > been executing along this general path [1]. >>> > >>> > On the 0.x line the next release would be 0.7.0. There does appear to >>> > be a lot of useful improvements/features/fixes there now and it is >>> > time to do a release according to our general 6-8 week approach. >>> > However, given all the effort going into 1.x I'd like to get a sense >>> > of what the community preference is. >>> > >>> > On the 1.0 line the release is coming into focus. Some things have >>> > moved into 1.x and some things look like they'd slide to the right of >>> > 1.x as is to be expected. For example distributed durability (HA >>> > Data) looks like a good thing to do post 1.0 given the substantive >>> > changes present from the new HA clustering approach and multi-tenant >>> > authorization. I'd also like to dive in and liberally apply Apache >>> > Yetus annotations [2] to all the things so we can be really explicit >>> > about what parts we can more freely evolve going forward. We've been >>> > a bit awkwardly hamstrung thus far without these so they should help >>> > greatly to better convey intent. >>> > >>> > For those really interested in things coming in the 1.0 release please >>> > take a look through the JIRAs currently there and provide comments on >>> > what is important to you, what you'd like to see moved out, in, etc.. >>> > [3]. At this point there are still a lot of things which will likely >>> > need to move out to allow the release to occur in a timely fashion. >>> > >>> > Also, keep in mind our stated release line/support model as found here >>> > >>> > [4]. >>> > >>> > >>> > [1] >>> > >>> > >>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E >>> > >>> > >>> > [2] >>> > >>> > >>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/ >>> > >>> > >>> > [3] >>> > >>> > >>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI >>> > >>> > >>> > [4] >>> > >>> > >>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management >>> > >>> > >>> > Thanks >>> > Joe >>> > >>> > >>> > >>> > >>> > >>> >> >>
