Proposal 1: MicroProfile releases support a minimum Jakarta EE versions
-
Given a MicroProfile release, specify a range of Jakarta EE dependencies, past and future. Possibly along the lines of “depends on Jakarta EE Core version y or above”.
o
The minimum Jakarta EE version would be specified in the MicroProfile umbrella specification like it currently is in the component specifications.
§
The minimum Jakarta EE Core Profile version would be 10 for MicroProfile 7
o
The Jakarta EE Core Profile API jar will be marked provided in the pom.xml as they are for the component specifications.
o
MP Implementations must pass the Jakarta EE TCK for the version and profile they implement.
o
It is expected that MP implementations and community will actively be participating in new EE releases, passing both TCKs and surfacing compatibility
issues eagerly.
§
Whenever a new EE release happens, MP needs to review whether the current release works with the new EE release. If not, a new MP release needs
to be done as soon as possible
o
If there are backwards compatibility issues that would prevent an implementation from passing the respective TCKs, those kinds of issues would
need to be addressed through the specification process (i.e. a major, minor or service release).
§
In the event proposal 1 is not possible because an implementation is not able to pass the TCK of both Jakarta EE.latest and MicroProfile, this
would be addressed through a MicroProfile spec update (essentially proposal 3).
o
MP Certification Requests (CCRs) must specify the exact Jakarta EE version and profile was implemented and passed in their certification results.
Q&A
o
How open-ended is this supposed to be? What if a Jakarta EE release breaks backwards compatibility? Who determines this without actually re-running
the TCK?
§
Implementations need to test it out before certifying against a higher of Jakarta EE
o
o
What is the TCK requirement for this?
§
Must pass Jakarta EE y+ TCKs and MicroProfile x TCKs
§
Some minor Jakarta EE releases could have backward incompatible changes by mistake. How do we account for that?
·
It means this Jakarta EE version can not work with the particular MP release. A new MP release have to be done to bring up the minimum version
of Jakarta EE.
§
If a MicroProfile component uses CDI 4.0, some aspects required must be CDI 4.0 or higher.
o
Cons:
§
Compromise portability as various implementations can support various Jakarta EE versions
o
Pros:
§
Allows implementations to align with Jakarta EE versions as they best see fit
§
Requires less frequent MicroProfile releases