You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Joe Witt <jo...@apache.org> on 2016/05/17 14:30:00 UTC
[DISCUSS] Apache NiFi 0.7.0 and 1.0.0
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
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Oleg Zhurakousky <oz...@hortonworks.com>.
Yes, it's on my list for 1.0
Oleg
> On Jun 1, 2016, at 08:33, Joe Witt <jo...@gmail.com> wrote:
>
> I had an off-list conversation with OlegZ about this recently and he
> said he planned on trying to tackle this for 1.x timing. Oleg - you
> have any updates you can share on the JIRA?
>
> It is definitely an important item for those that want to do effective
> CM which is diff friendly. Is just a step of many we should take to
> make the whole dev/ops lifecycle for a flow as good as possible.
>
>> On Wed, Jun 1, 2016 at 8:28 AM, Edgardo Vega <ed...@gmail.com> wrote:
>> What ever happened to the following from the 6-12 month roadmap that was
>> posted a while ago?
>>
>> Deterministic Template Export
>> https://issues.apache.org/jira/browse/NIFI-826
>>
>>> On Tue, May 31, 2016 at 10:07 PM, Joe Witt <jo...@gmail.com> wrote:
>>>
>>> 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 <rh...@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 <rh...@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 <jo...@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 <al...@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
>>>>>>> alopresto@apache.org
>>>>>>> alopresto.apache@gmail.com
>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>>>>>>
>>>>>>> On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <alopresto@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
>>>>>>> alopresto@apache.org
>>>>>>> alopresto.apache@gmail.com
>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>>>>>>
>>>>>>> On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
>>>>>>> <oz...@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 <jv...@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 <jo...@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
>>
>>
>>
>> --
>> Cheers,
>>
>> Edgardo
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Joe Witt <jo...@gmail.com>.
I had an off-list conversation with OlegZ about this recently and he
said he planned on trying to tackle this for 1.x timing. Oleg - you
have any updates you can share on the JIRA?
It is definitely an important item for those that want to do effective
CM which is diff friendly. Is just a step of many we should take to
make the whole dev/ops lifecycle for a flow as good as possible.
On Wed, Jun 1, 2016 at 8:28 AM, Edgardo Vega <ed...@gmail.com> wrote:
> What ever happened to the following from the 6-12 month roadmap that was
> posted a while ago?
>
> Deterministic Template Export
> https://issues.apache.org/jira/browse/NIFI-826
>
> On Tue, May 31, 2016 at 10:07 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> 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 <rh...@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 <rh...@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 <jo...@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 <al...@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
>> >>> > alopresto@apache.org
>> >>> > alopresto.apache@gmail.com
>> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>> >>> >
>> >>> > On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <alopresto@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
>> >>> > alopresto@apache.org
>> >>> > alopresto.apache@gmail.com
>> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>> >>> >
>> >>> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
>> >>> > <oz...@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 <jv...@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 <jo...@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
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>>
>
>
>
> --
> Cheers,
>
> Edgardo
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Edgardo Vega <ed...@gmail.com>.
What ever happened to the following from the 6-12 month roadmap that was
posted a while ago?
Deterministic Template Export
https://issues.apache.org/jira/browse/NIFI-826
On Tue, May 31, 2016 at 10:07 PM, Joe Witt <jo...@gmail.com> wrote:
> 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 <rh...@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 <rh...@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 <jo...@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 <al...@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
> >>> > alopresto@apache.org
> >>> > alopresto.apache@gmail.com
> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >>> >
> >>> > On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <alopresto@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
> >>> > alopresto@apache.org
> >>> > alopresto.apache@gmail.com
> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >>> >
> >>> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
> >>> > <oz...@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 <jv...@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 <jo...@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
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>
> >>
>
--
Cheers,
Edgardo
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Joe Witt <jo...@gmail.com>.
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 <rh...@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 <rh...@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 <jo...@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 <al...@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
>>> > alopresto@apache.org
>>> > alopresto.apache@gmail.com
>>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>> >
>>> > On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <al...@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
>>> > alopresto@apache.org
>>> > alopresto.apache@gmail.com
>>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>> >
>>> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
>>> > <oz...@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 <jv...@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 <jo...@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
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Ryan H <rh...@gmail.com>.
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 <rh...@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 <jo...@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 <al...@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
>> > alopresto@apache.org
>> > alopresto.apache@gmail.com
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>> >
>> > On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <al...@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
>> > alopresto@apache.org
>> > alopresto.apache@gmail.com
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>> >
>> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
>> > <oz...@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 <jv...@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 <jo...@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
>> >
>> >
>> >
>> >
>> >
>>
>
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Ryan H <rh...@gmail.com>.
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 <jo...@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 <al...@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
> > alopresto@apache.org
> > alopresto.apache@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >
> > On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <al...@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
> > alopresto@apache.org
> > alopresto.apache@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >
> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
> > <oz...@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 <jv...@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 <jo...@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
> >
> >
> >
> >
> >
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Joe Witt <jo...@gmail.com>.
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 <al...@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
> alopresto@apache.org
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <al...@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
> alopresto@apache.org
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
> <oz...@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 <jv...@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 <jo...@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
>
>
>
>
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Andy LoPresto <al...@apache.org>.
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On May 17, 2016, at 3:43 PM, Joe Witt <jo...@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 <mo...@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 <jo...@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 <al...@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
>>>> alopresto@apache.org
>>>> alopresto.apache@gmail.com
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>>>
>>>> On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
>>>> <oz...@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 <jv...@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 <jo...@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
>>>>
>>>>
>>>>
>>>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Joe Witt <jo...@gmail.com>.
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 <mo...@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 <jo...@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 <al...@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
>> > alopresto@apache.org
>> > alopresto.apache@gmail.com
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>> >
>> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
>> > <oz...@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 <jv...@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 <jo...@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
>> >
>> >
>> >
>>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Michael Moser <mo...@gmail.com>.
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 <jo...@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 <al...@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
> > alopresto@apache.org
> > alopresto.apache@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >
> > On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
> > <oz...@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 <jv...@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 <jo...@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
> >
> >
> >
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Joe Witt <jo...@gmail.com>.
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 <al...@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
> alopresto@apache.org
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
> <oz...@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 <jv...@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 <jo...@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
>
>
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Andy LoPresto <al...@apache.org>.
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On May 17, 2016, at 1:19 PM, Joe Witt <jo...@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
> <oz...@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 <jv...@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 <jo...@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
>>>>
>>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Joe Witt <jo...@gmail.com>.
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
<oz...@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 <jv...@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 <jo...@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
>>>
>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by Oleg Zhurakousky <oz...@hortonworks.com>.
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 <jv...@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 <jo...@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
>>
Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Posted by James Wing <jv...@gmail.com>.
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 <jo...@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
>