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 >>> >
