|Re: [jakartaee-platform-dev] Fair rules for"optional" TCKcompliance tests|
I don’t think the EFSP has to be changed either. The wording may be hard to understand not just by simple guys, but when turning a feature optional or even removing is concerned we should be able to make all changes in the spec that help formalize this.
Being a simple guy and following the mantra “If you can’t kick it it doesn’t exist”. I suggest that when planning Jakarta EE 10 if no member of the working group plans to implement a feature/specification that we would like to declare optional we simply remove it from the platform spec. That way there is no change required to the EFSP.
If somebody would like to implement it later then I suggest the specification moves or feature becomes standalone with a release cadence decoupled from the overall platform spec.
Note that if there is a single implementation that wishes to support an Optional specification and and wants to retain it in the overall platform specification then they have to agree to be on the critical path for delivery.
By the way, if we go ahead to make the spec change. I will suggest not to require a compatible implementation to implement Optional features. I think what David suggested to require implementations in aggregation implement all optional features has a few issues:
1. An optional feature might not be covered by any implementations. What do we do with it?
2. This might delay the spec release as it has to wait for a few implementations to cover all optional features. There will be some uncertainty.
3. If there is integration among optional features, these will be untested if we spread the optional features among multiple implementations.
I think simply not forcing implementation implements optional features makes sense and we then remove the optional features in the future releases.
On Mon, Jul 6, 2020 at 11:15 AM Werner Keil <werner.keil@xxxxxxx> wrote:
Back to the top