The API should be Independent from the implementation, there is no Concept of an RI in Jakarta EE anyway ;-)
So I suggest to go for the API first and look at what the implementation can do a few weeks later.
I don’t think the compatibility requirements are already as strong as having to list all compatible implementations that implement THAT very version of the API Prior to a Final release, correct me @Ivar if that’s needed at this stage O;-)
Gesendet von Mail für Windows 10
Yeap, there is not blocker on the API side.
But does it make sense to release an API version without release a RI?
I would say for the Jakarta Spec and API the dependency on MicroProfile does not really block us, and should the compatible implementation have ongoing Problems due to that, it might be an issue there, but I see no reason to wait much longer on the API side.
It has been over six months since the last version.
I want to release a new version, 1.0.0-b3:
- Remove JNoSQL logo from repositories
- Remove "Artemis" references in the package and use "mapping" instead.
- Remove "diana" references in the package name and use "communication" instead.
- Update Cassandra library to use DataStax OSS
- Fixes HashMap issue in the mapping API
PS: We are still waiting to discuss the integration between Eclipse MicroProfile and Jakarta EE to check how the MicroProfile dependency will ok.
jnosql-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jnosql-dev