<div dir="ltr">The following branches in the incubator are the proposed changes that will kick this off for the 2.x releases of WildFly Elytron: -<div><br></div><div><a href="https://github.com/wildfly-security-incubator/wildfly-elytron/tree/2.x">https://github.com/wildfly-security-incubator/wildfly-elytron/tree/2.x</a><br></div><div><a href="https://github.com/wildfly-security-incubator/wildfly-elytron-ee">https://github.com/wildfly-security-incubator/wildfly-elytron-ee</a><br></div><div><a href="https://github.com/wildfly-security-incubator/wildfly-elytron-mp">https://github.com/wildfly-security-incubator/wildfly-elytron-mp</a><br></div><div><br></div><div>I have verified that we can still use the tools provided by git to merge from the 1.x branch to the three new branches / repos so development for WildFly will continue in the existing 1.x branch.</div><div><br></div><div>Most importantly I can also apply the changes to the master branch of Elytron as used by Quarkus so I can create them a .Final release without EE or MP dependencies and without causing the repo to yoyo between Jakarta EE 8 and 9 as that is handled in independent modules.</div><div><br></div><div>The modules that have been split out retain the same group and artifact ID as they had when contained within the main Elytron project, the only difference with this change is that they will no longer be shaded into the wildfly-elytron jar.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2020 at 2:19 PM Darran Lofthouse &lt;<a href="mailto:darran.lofthouse@jboss.com">darran.lofthouse@jboss.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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: -</div><div><br></div><div> * Elytron 1.x - Jakarta EE 8</div><div> * Elytron 2.x - Jakarta EE 9</div><div> * Elytron 3.x - Jakarta EE 8</div><div> * Elytron 4.x - Jakarta EE 9</div><div><br></div><div>So instead to simplify our versioning I was going to consider we pull the spec related modules out into their own projects: -</div><div><br></div><div>    wildfly-elytron-ee and wildfly-elytron-mp</div><div><br></div><div>This would mean our Elytron release streams would become: -</div><div><br></div><div><div> * Elytron 1.x - Jakarta EE 8</div><div> * Elytron 2.x - No Jakarta modules, compatible with 1.x.</div><div> * Elytron 3.x - No Jakarta modules, some breaking changes.</div><div><br></div><div>The new modules would then align with Elytron 2.x and handle the move to Jakarta EE 9 within their own version ranges.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div><div></div></div><div><br></div></div>
</blockquote></div>