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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > [email protected] > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > On May 17, 2016, at 1:19 PM, Joe Witt <[email protected]> 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 > > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > > > > >
