At some point in the future we are going to need to consider a migration to Jakarta EE 9 so I just wanted to raise some ideas as to how we may choose to structure the project.
As it stands today our 1.x releases are being used for WildFly and in each release we are maintaining compatibility of the public API against the previous releases. We have also started with our 2.0.x releases where some compatibility has been broken to clean up inter package dependencies, we were planning to tag this as .Final for Quarkus.
If we are going to switch to Jakarta EE 9 which means new packages for the specifications that feels like we should handle that with a major version bump. My first idea was we move master to 3.x and insert a new 2.0.x release which maintains compatibility with 1.x other than the Jakarta changes but considering other requirements on us that would lead us to: -
* Elytron 1.x - Jakarta EE 8
* Elytron 2.x - Jakarta EE 9
* Elytron 3.x - Jakarta EE 8
* Elytron 4.x - Jakarta EE 9
So instead to simplify our versioning I was going to consider we pull the spec related modules out into their own projects: -
wildfly-elytron-ee and wildfly-elytron-mp
This would mean our Elytron release streams would become: -
* Elytron 1.x - Jakarta EE 8
* Elytron 2.x - No Jakarta modules, compatible with 1.x.
* Elytron 3.x - No Jakarta modules, some breaking changes.
The new modules would then align with Elytron 2.x and handle the move to Jakarta EE 9 within their own version ranges.
Regards,
Darran Lofthouse.