This is around the time I would like to be recommending that we stabilize what we have in version 1.0 in preparation to for having a completed specification, TCK, and at least one compatible implementation in beta release at a minimum in
time for the approaching Jakarta EE 11 component specification release review deadline in April.
Unfortunately, this also coincides with a massive influx of new proposals for Jakarta Data that I cannot keep up with reviewing, let alone ensuring there will be TCK coverage and a compatible implementation for them. While it is wonderful
to see all of the interest and contributions, I would like to ask everyone to please limit proposals for 1.0 to what is truly needed. If you have an idea that isn’t truly necessary for version 1.0, by all means open an issue, but tag it for a Milestone of
Future (or if you aren’t a committer, post a comment indicating so) so that we focus on achieving the 1.0 release.
It is also important to consider which vendor(s) can step up to supply a beta release of a compatible implementation before the April deadline. For a while, I had assumed we could always fall back to Open Liberty for this if need be, which
up until now had kept up an implementation passing the TCK that could be used if we agreed to finish off the specification and TCK and produce an RC1 (release candidate 1) by March 20 (around a month from now). However, with the large volume of changes and
new capability that is being requested for 1.0, I can say that it neither looks possible for the new spec activity to have wound down by that point, nor for Open Liberty to have implemented the large amount of changes being proposed by then.
We need a vendor to step up and commit to providing a compatible implementation in a minimum beta release of their product fully passing the TCK in time to meet the April deadline for EE 11 component spec release reviews. If we do not
meet this deadline, Jakarta Data will not be part of Jakarta EE 11.
Again, I would like everyone to give some thought about whether we really want to be making changes at this point. We started out the week with our spec in a great position, highly likely to make EE 11. It is now in a position where I
would say it is highly unlikely to make EE 11 unless participants can be willing to severely limit the amount of changes going in at this point.