[
https://issues.apache.org/jira/browse/HADOOP-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16164954#comment-16164954
]
Miklos Szegedi commented on HADOOP-13714:
-----------------------------------------
[~templedf], thank you for working on this. I read the document and I have a
few comments and questions.
It would be helpful to have a shorter version or summary at the beginning for
general audience.
It could make sense to add a glossary. It might not be obvious to everyone for
example what is downstream.
bq. A package, class, or member variable or method that is not annotated SHALL
be interpreted as implicitly Private and Unstable.
bq. In cases where no classifications are present, the protocols SHOULD be
assumed to be Private and Stable.
Please help me understand the difference between protocols and code, why that
they are treated so much differently. I would assume a code that is not marked
as unstable should be stable.
bq. Each API has an API-specific version number. Any incompatible changes MUST
increment the API version number.
I would also elaborate, whether the old API versions should be supported or
not. In what circumstances can a REST API version be deprecated or removed.
bq. All audit log output SHALL be considered Public and Stable. Any change to
the data format SHALL be considered an incompatible change.
Since this is an audit log, I am assuming a security requirement may override
this requirement. Let’s say a certain event was not logged before but it should
be.
bq. The environment variables consumed by Hadoop and the environment variables
made accessible to applications through YARN SHALL be considered Public and
Evolving. The developer community SHOULD limit changes to major releases.
Just a note. Hadoop configuration is public and stable. Do environment
variables passed to the AM need to be evolving?
bq. The JVM requirements SHALL NOT change across minor releases within the same
major release unless the JVM version in question becomes unsupported. The JVM
version requirement MAY be different for different operating systems or even
operating system releases.
Regarding this let’s call out C compiler and and runtime requirements. It might
be frustrating not to be able to compile a new minor version of Hadoop with a
security fix on an existing tested configuration.
> Tighten up our compatibility guidelines for Hadoop 3
> ----------------------------------------------------
>
> Key: HADOOP-13714
> URL: https://issues.apache.org/jira/browse/HADOOP-13714
> Project: Hadoop Common
> Issue Type: Improvement
> Components: documentation
> Affects Versions: 2.7.3
> Reporter: Karthik Kambatla
> Assignee: Daniel Templeton
> Priority: Blocker
> Attachments: Compatibility.pdf, HADOOP-13714.001.patch,
> HADOOP-13714.002.patch, HADOOP-13714.003.patch, HADOOP-13714.004.patch,
> HADOOP-13714.WIP-001.patch, InterfaceClassification.pdf
>
>
> Our current compatibility guidelines are incomplete and loose. For many
> categories, we do not have a policy. It would be nice to actually define
> those policies so our users know what to expect and the developers know what
> releases to target their changes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
