[
https://issues.apache.org/jira/browse/HADOOP-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674828#action_12674828
]
Doug Cutting commented on HADOOP-5203:
--------------------------------------
> I do still believe that this including the date will cause this problem
> (which now has a supported work-around) to occur for other people using other
> build systems.
And Owen feels strongly that the current behavior protects us against real
hazards. He's had clusters that only partially upgraded and encountered
unexpected difficult to diagnose problems. We need to reach a consensus. So
the question is not whether this is the way you would implement this in a
vacuum, but whether this is a solution that we can all agree to. Do you have
an alternate proposal that you prefer that Owen might support? If not, can you
live with the solution I suggested?
> TT's version build is too restrictive
> -------------------------------------
>
> Key: HADOOP-5203
> URL: https://issues.apache.org/jira/browse/HADOOP-5203
> Project: Hadoop Core
> Issue Type: Bug
> Components: mapred
> Affects Versions: 0.19.0
> Reporter: Runping Qi
> Attachments: HADOOP-5203.patch
>
>
> At start time, TT checks whether its version is compatible with JT.
> The condition is too restrictive.
> It will shut down itself if one of the following conditions fail:
> * the version numbers must match
> * the revision numbers must match
> * the user ids who build the jar must match
> * the build times must match
> I think it should check the major part of the version numbers only (thus any
> version like 0.19.xxxx should be compatible).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
