[[appeals-process]]

== Appeals Process

While the Jakarta Core Profile TCK is rigorous about enforcing an implementation's conformance to the Jakarta Core Profile specification, it's reasonable to assume that an implementor may discover new and/or better ways to validate the assertions.
The appeals process is defined by the Jakarta EE
link:$$https://jakarta.ee/committees/specification/tckprocess/$$[Jakarta EE TCK Process {tck-process-version}]


=== What challenges to the TCK may be submitted?

Any test case (e.g., test class, +@Test+ method), test case configuration (e.g., beans.xml), test beans, annotations and other resources may be challenged by an appeal.

What is generally not challengeable are the assertions made by the specification. The specification document is controlled by a separate process and challenges to it should be handled by sending an e-mail to mailto:jakartaee-platform-dev@eclipse.org[Platform Dev List]

=== How these challenges are submitted?

To submit a challenge, a new issue should be created in the link:$$https://github.com/eclipse-ee4j/jakartaee-platform/issues$$[Jakarta Platform Project] using the label challenge. Any communication regarding the issue should be pursed in the comments of the filed issue for accurate record.

=== How and by whom challenges are addressed?

The challenges will be addressed in a timely fashion by the platform dev team.


=== How accepted challenges to the TCK are managed?
The worflow for TCK challenges is outlined in
link:$$https://jakarta.ee/committees/specification/tckprocess/$$[Jakarta EE TCK Process {tck-process-version}].

Periodically, an updated TCK will be released, containing tests altered due to challenges - no new tests will be added. Implementations are required to pass the updated TCK. This release stream is named {revnumber}.x, where x will be incremented.


