Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] TCK Issues to Resolve

Some initial thoughts inline below. Sorry but I won’t be on the call today.

 

From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Richard Monson-Haefel
Sent: 22 August 2018 13:25
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [jakarta.ee-spec.committee] TCK Issues to Resolve

 

The Draft of the TCK document (see link below) has been available and commented on.  More comments are welcome.

 

https://docs.google.com/document/d/1civpv_KLHvUXgILQYCh0HR9Xgsv78PISPc9wbRUUKMc/edit?usp=sharing

 

While some issues are easy to resolve in comments on the document others require a more focused resolution. These other issues are enumerated below.  Please take the time to read and respond.

  1. TCK Challenges: When a vendor challenges a TCK test who should determine if the challenge is valid?   The following options have been suggested:
    • The TCK Project (assuming its separate from the Specification Project)

We have found this challenging in MicroProfile the developer of a test can be very defensive when challenged especially as the test works on their implementation. For example in MicroProfile the test suite needs a lot of “massaging” to work using some Arquillian connectors in a remote profile. I would say the three bullet described are the escalation path. First raise a PR in TCK project, if this is not fruitful the spec project then final arbitration spec committee.

    • The Specification Project with Escalation to the Specification Committee allowed
    • The Specification Committee only.

 

  1. Vendor Releases and TCK patches:  If a vendor releases a new version minor of their product, which continues to support the same specifications claimed by the original major version, can the new minor version be tested against the original TCK used for the original version, or does it need to be tested against the latest patch/revision of that TCK?

I would say that the vendor has to state which version of the TCK they pass and therefore does not have to pass a patched TCK immediately as this could be disruptive to release cycles. Perhaps you could add a requirement to pass within x number of months of a new version?

  1. Versioning:  Should the TCK versions match the major and minor versions of the Specification?

I would say major and minor yes as JAX-RS 2.0 is different to JAX-RS 2.1. However the TCK should be allowed to have 3rd level versioning e.g. TCK 2.1.1 which does not require a spec update. For example to fix some tests etc. as this would not require a spec doc update.

  1. Versioning:  If an errata level error (anything that doesn't change the described behavior of the software or its API usage) is found in a specification which of the following options should we use?
    • An errata is published with the correction but the specification is not updated.
    • The specification is updated and a new Rev version is released. (e.g. X Specification Version 1.2 Rev 2)
    • The specification is updated and a new Maintenance version is released (e.g. X Specification Version 1.2 MR 2)

No real preference. I suppose it depends on how heavyweight the process is to release a maintenance release cf update an errata.

  1. Specification Updates and TCK updates:  What kinds of corrections to a specification should require a new version of the TCK?

Anything that would invalidate a currently active test or require an additional test. Therefore for an existing test (and I may get this wrong) anything that strengthens postconditions and preconditions.

 

thanks,

 

Richard

 

 

 

Back to the top