|Re: [jakarta.ee-spec] Proposal to update TCK process text to explicitly allow test modification after a challenge|
I’d like to propose adjusting the TCK process for a service release in response to a challenge.
In the recent Batch TCK v2.1.1 service release:
we addressed a challenge by modifying a test, and “loosening” the validation logic.
Now, I think a straightforward reading of the TCK process
suggests this isn’t allowed… you can only exclude the test or workaround.
If it weren’t for Scott Marlow voicing his support for the idea, https://github.com/eclipse-ee4j/batch-tck/issues/49#issuecomment-1145335955
I’d have assumed we couldn’t do this.
The key point was ensuring that, with this modification, any implementation passing the old test should also pass the new, modified test.
Abstracting over the details… instead of verifying that variable “a” was set to value “XYZ” we allowed for either “a” OR “b” to be set to value “XYZ”.
I am in favor of the change, since it allows us to avoid throwing away a useful test ( and we did go ahead and do the change and v2.1.1 release).
But I’m circling back here with this email, and this PR I drafted on the subject:
clarifies that I was incorrect about the current TCK Process
document. I'm going to suggest an additional change to be
considered as an additional PR to be merged with yours.
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
Back to the top