Joe As a general rule, breaking changes will happen in any and every framework and/or product - as a general fact of life. And that is what I meant with my statement. Having said that I do admit that reading it again comes across as if the decision about the approach proposed in the wiki has been made. That is not correct, so my bad. So, Josh, no decisions about anything has been made and as you can see its a very interesting discussion on the wiki.
Cheers Oleg > On Jan 18, 2016, at 5:37 PM, Joe Witt <[email protected]> wrote: > > Oleg, > > "Yes, there will be breaking changes. Its not a question of IF, but > rather WHEN." > > I disagree. It is always a question of IF. > > We have to be extremely judicious in the use of breaking changes and > we owe the user/developer based excellent justification in such cases. > > I will comment on the Wiki page for the substance of this particular > proposal (documentation generation). > > Joe > > On Mon, Jan 18, 2016 at 1:22 PM, Oleg Zhurakousky > <[email protected]> wrote: >> Josh >> >> FWIW, let’s use WIKI comments to maintain a discussion. It will be simpler >> in the end to compile a resolution and move on. >> >> Yet, I’ll reply here anyway. >> Yes, there will be breaking changes. Its not a question of IF, but rather >> WHEN. >> What we can do is make it less painful by introducing certain changes >> gradually with deprecations and clear communication to the community on what >> is about to change. Other mechanics could be applied here as well, but >> before we get into the mechanics, I’d like to see if there are any more >> ideas, concerns etc, so we can have a join resolution as to what is a >> sustainable documentation model of the future NiFi, then we can figure out >> how to get there. >> >> Cheers >> Oleg >> >>> On Jan 18, 2016, at 1:08 PM, Joshua Davis <[email protected]> wrote: >>> >>> Oleg, >>> >>> Interesting document, what impact would it have on existing installations >>> of NIFI? >>> >>> What would be the upgrade path for Custom Processors? >>> >>> Are we breaking compatibility with the previous way of doing documentation? >>> >>> Why not create a simple content repository that can hold the documentation >>> information? >>> >>> Is there a plan for multiple languages? >>> >>> Joshua Davis >>> Senior Consultant >>> Hortonworks Professional Services >>> (407)476-6752 >>> >>> >>> >>> >>> >>> >>> On 1/18/16, 12:09 PM, "Oleg Zhurakousky" <[email protected]> >>> wrote: >>> >>>> Guys >>>> >>>> I¹ve just finished initial draft of the proposal to improve our component >>>> documentation mechanisms (e.g., Processors, ControllerServices etc). >>>> https://cwiki.apache.org/confluence/display/NIFI/Component+documentation+i >>>> mprovements >>>> Please give it a read and let¹s get discussion going. >>>> >>>> Cheers >>>> Oleg >>> >>> >> >
