[wildfly-dev] WildFly Elytron - Module Structure

[Darran Lofthouse]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200128/702b8291/attachment.html