I have no objection to "because we should be able to do this well!" as a
reason.
On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:
> Generally RCs are used to address that level of validation, so in the end
> I still think it's a more of a culture one choose
Generally RCs are used to address that level of validation, so in the end I
still think it's a more of a culture one chooses. One common example; x.x.1+ =
maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major features.
In any event IMHO the ability to quickly release maintenance releas
On Thu, Dec 17, 2015 at 6:32 PM, Tony Kurc wrote:
> I'm not sure I understand "more validation" reasoning - won't features at
> the end have very little validation?
>
> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue wrote:
>
> > Another reason to release 0.4.1 is to allow the additions that warrant
Yes, which affects when you time getting something into master. Larger
features that are done just before a release (more risk) can get pushed
so that they are committed after a release instead of just before one.
Regular releases ensure the penalty for choosing to get into the next
release are
I'm not sure I understand "more validation" reasoning - won't features at
the end have very little validation?
On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue wrote:
> Another reason to release 0.4.1 is to allow the additions that warrant
> 0.5.0 to have more validation before release. With a regular
Another reason to release 0.4.1 is to allow the additions that warrant
0.5.0 to have more validation before release. With a regular release
cycle, features can go in at the beginning to have more time for
catching bugs in them. I also agree with what Sean said below.
rb
On 12/17/2015 04:00 PM
On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc wrote:
> s/features/buxfixes/
>
> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc wrote:
>
> > Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
> > features onto 0.4.1?
> >
>
This is a good question.
Some downstream users might have diff
I wouldn't want to see the kafka client upgrade in a patch release.
On Thu, Dec 17, 2015 at 5:37 PM, Joe Witt wrote:
> OK thanks for confirming proper git fu.
>
> Yeah I was meaning to just grab bugs. The master branch already has stuff
> that seems to warrant a minor bump (maybe) so wanted to
s/features/buxfixes/
On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc wrote:
> Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
> features onto 0.4.1?
>
> On Thu, Dec 17, 2015 at 6:38 PM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
>> I think we want to exclude new f
Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
features onto 0.4.1?
On Thu, Dec 17, 2015 at 6:38 PM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:
> I think we want to exclude new features and make it a true maintenance
> release, so only bugs should go into 0.4.1
>
I think we want to exclude new features and make it a true maintenance release,
so only bugs should go into 0.4.1
> On Dec 17, 2015, at 6:17 PM, Matt Gilman wrote:
>
> Are there some commits on master that we don't want included in 0.4.1? If
> not, wouldn't we just follow our normal rele
OK thanks for confirming proper git fu.
Yeah I was meaning to just grab bugs. The master branch already has stuff
that seems to warrant a minor bump (maybe) so wanted to understand a bug
only route.
Matt understand your point on dependent commits. Will check that out.
Thanks
Joe
On Dec 17, 201
I see, that does appear to be the case. What your suggesting sounds good.
Though we should review the tickets that addressed UI bugs/improvements. I
realize you probably specifically just chose the JIRAs that addressed bugs.
I'd want to make sure that the tickets included don't have a dependency on
Are there some commits on master that we don't want included in 0.4.1? If
not, wouldn't we just follow our normal release process?
Matt
On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue wrote:
> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
> makes sense to me.
>
> rb
>
>
> O
Sounds reasonable to me. branching off of the last release tag and then
cherry picking a conservative subset of fixes for a patch release has
worked well for me on another project.
It's implied in your email, but just to confirm, you're only suggesting
grabbing *some* of the currently-in-0.5.0 iss
Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
makes sense to me.
rb
On 12/17/2015 12:29 PM, Joe Witt wrote:
team,
matt clarke just discovered an interesting case that appears to expose
a defect in site-to-site. The details of it are still being worked
out as you can
team,
matt clarke just discovered an interesting case that appears to expose
a defect in site-to-site. The details of it are still being worked
out as you can see in NIFI-1301. And this issue has been around for a
very long time but it still feels like something worth addressing in
an incrementa
Jeff, I've answered inline. Thanks for using the processor, sorry it
isn't clear what's happening.
rb
On 11/05/2015 01:59 PM, Jeff wrote:
I built a simple flow that reads a tab separated file and attempts to convert
to Avro.
ConvertCSVtoAvro just says that the conversion failed.
Where can I
GitHub user jskora opened a pull request:
https://github.com/apache/nifi/pull/145
NIFI-1300 - Penalize flowfiles when message send or commit exceptions occur
and mâ¦
â¦ake commit exception handler route to failure instead of rolling back.
Moved producer queue creation into a met
Ian,
Excellent catch, I was referring to the ConvertAvroToJSON processor, which
can EMIT json with either representation, which is obvious in retrospect
*not* what was being asked:
http://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.avro.ConvertAvroToJSON/index.html
On Thu
trkurc, Am i missing something, I do not see the functionality to toggle
between the two json representations in the latest build of jsontoavro
processor?
Ian
--
View this message in context:
http://apache-nifi-developer-list.39713.n7.nabble.com/JSON-Avro-issues-tp3923p5828.html
Sent from the
Shweta,
Take a look at InvokeHTTP[1] instead of GetHTTP. InvokeHTTP allows
Expression Language in the URL, so you can specify the page number. Let us
know if you have any other questions. Thanks.
[1]
http://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.Invo
Hi All,
I have a requirement wherein I have to update getHTTP URL dynamically.
Within that url I have
a parameter called page whose value can vary from 1 to N number depending
upon no. of pages present.
My requirement is as such that "nextInt()" would not be useful. I want to
define my own par
23 matches
Mail list logo
