[ 
https://issues.apache.org/jira/browse/FLUME-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426862#comment-13426862
 ] 

Hari Shreedharan edited comment on FLUME-1393 at 8/1/12 8:05 PM:
-----------------------------------------------------------------

Just answering your questions:
1) Very important - We cannot break backward compatibility between point 
releases. It can be considered for Flume 2.0 - which can have non-backward 
compatible options, as is the standard practice in case of software.

2) a is better, but we cannot move to a if it will in anyway affect current 
users. A point release upgrade should be seamless and the user should not have 
to change anything after the upgrade (unless he wants to use new fatures 
introduced by the new version).


                
      was (Author: hshreedharan):
    Just answering your questions:
1) Very important - We cannot break backward compatibility between point 
releases. It can be considered for Flume 2.0 - which can have non-backward 
compatible options, as is the standard practice in case of software.

2) a is better, but we cannot move to a if it will in anyway affect current 
users. A point release upgrade should be seamless and the user should not have 
to change anything after the upgrade.


                  
> Create a tooling framework for Flume
> ------------------------------------
>
>                 Key: FLUME-1393
>                 URL: https://issues.apache.org/jira/browse/FLUME-1393
>             Project: Flume
>          Issue Type: Improvement
>            Reporter: Patrick Wendell
>
> Flume should have a tools framework that allows for pluggable tools which can 
> be launched from the existing Flume shell. This would let developers write 
> tools that can be launched with the Flume classpath and configuration 
> information. This would look like:
> - Have a flume-ng-tools project where individual tools create sub-projects
> - A given tool sub-project would include the source code for the tool and a 
> configuration file saying (a) the full classname of the tool and (b) a short 
> name
> - There would be a outer layer runner class called by flume-ng which can be 
> called with an arbitrary short-name and will lookup and correctly load and 
> execute the tool being referenced
> - The flume-ng script would decide whether it thinks a tool is being 
> referenced in the argument and if so would delegate to the runner class 
> (otherwise, the logic stays the same for agent/version).
> This is just a first draft of how this will look - stay tuned for further 
> comments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to