|Re: [jakartaee-platform-dev] Fair rules for"optional" TCKcompliancetests|
Not sure, if they can simply be dropped from Jakarta EE 9 in the middle of the road?
E.g. Jakarta EE 8 had among others 2.7.4. RMI-IIOP (Proposed Optional)
Which became 2.7.4. RMI-IIOP (Removed) guess the lack of support was what turned "Optional" into "Removed" but without a "Proposed something" in Jakarta EE 9 how could we just delete things without prior notice?
Maybe since EE 9 will break all sorts of compatibility anyway without using some Transformer Magic or similar, it is even acceptable in this particular case, but further down the road it would a fatal signal to the community regarding reliability and stability and that’s a major reason to use Jakarta EE instead of some random framework or a solution that’s tied to a vendor’s mercy and may change quite often.
Ford was betting big on Pivotal in 2016, and last year this cost them almost more than rival Tesla or the COVID19 crisis: https://www.theregister.com/2019/07/25/pivotal_ford_write_down/
Dell wants to sell VMWare for similar reasons, and nobody knows, what cuts may result if some "locust" investor gobbles it up and decides to eliminate parts of Spring they feel are not cost-effective any more?
So this time with Jakarta EE 9 "Big Bang" transition maybe something can be dropped a little sooner than expected, but in future versions I would be more careful to avoid doing that without enough notice.
Exactly. Hence, unless some sponsor is explicitly stepping up to bring the EE9 specs, their TCKs and an implementation across the finish line, those specs need to be dropped from the EE9 platform.
On Mon, Jul 6, 2020 at 8:28 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
Back to the top