[ 
https://issues.apache.org/jira/browse/HADOOP-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521513
 ] 

Doug Cutting commented on HADOOP-1436:
--------------------------------------

> the changes.txt log should be in the INCOMPATIBLE CHANGES section rather than 
> IMPROVEMENTS

I don't think a deprecation is an incompatibility.  It doesn't break user code.

Our pattern is to try to deprecate things in one release, then remove them in a 
subsequent release.  Then user code can run unchanged with each new release, so 
that the release may be easily evaluated.  And, if after upgrading, you remove 
all uses of deprecated code, then you'll be able to upgrade to the next 
release.  The question is, where in that cycle is the incompatible change?

Arguably, for applications that play by the rules (removing use of deprecated 
features in the current release before upgrading to the next release) there are 
no incompatible changes in this cycle.  Even if we do want to label such 
deprecation/removal cycles as incompatible changes, we should probably choose 
one event or the other, deprecation or removal, as the incompatible step.  I'd 
probably opt for removal, not deprecation.  Thoughts?

> Redesign Tool and ToolBase API and releted functionality
> --------------------------------------------------------
>
>                 Key: HADOOP-1436
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1436
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: util
>    Affects Versions: 0.15.0
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 0.15.0
>
>         Attachments: redesignToolAndRelated_v1.0.patch, 
> redesignToolAPI_v1.1.patch, redesignToolAPI_v1.2.patch, 
> redesignToolAPI_v1.3.patch
>
>
> With the discussion from HADOOP-1425, we need better abstraction and better 
> tool runner utilities. 
> 1. Classes do not need to extend ToolBase 
> 2. functions for parsing general HadoopCommands (-fs, -conf, -jt) should be 
> public
> 3. We need a ToolRunner, or similar functionality 
> 4. Also we need each class (implementing Tool) to be runnable (main method)
> 5. CLI objects can be passed to run method of the Tool class (arguable)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to