Hello, Any tentative timeline about when we can expect 6.0.0 to be available for use
Regards, Jayeshkumar On Sun, 17 Sept, 2023, 10:12 pm Jean-Baptiste Onofré, <j...@nanthrax.net> wrote: > Hi all, > > I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including > schemas update, etc). > > I will now move forward on the related changes. > > Thanks all, > Regards > JB > > On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich <mattr...@gmail.com> wrote: > > > > Sounds good, makes sense. > > > > Thanks, > > Matt > > > > > On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > > > I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x > > > changes to jakarta.jms. > > > > > > So we are fully aligned and it shows that ActiveMQ 6.x is cleaner. > > > If users want to still use javax.jms then they will use ActiveMQ 5.x, > > > if they want to use jakarta.jms, they will use ActiveMQ 6.x. > > > > > > It's clear like this imho. > > > > > > Regards > > > JB > > > > > > On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell < > robbie.gemm...@gmail.com> wrote: > > >> > > >> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the > > >> broker side and also uses the same classes as the client for various > > >> stuff, so it has to be fully converted so you can use broker + client > > >> in the same application/test without resorting to containers etc. The > > >> 5.x javax broker and jakarta client simply cant be used in the same > > >> classloader. > > >> > > >> 5.x also uses Spring for various bits and a jakarta conversion means > > >> using Spring 6, which requires Java 17 as you noted (related aside: 17 > > >> wont be the current LTS as of next week, with Java 21 > > >> releasing...which has effectively been finalised for a month now since > > >> there was no RC2). > > >> > > >> So essentially it is not as simple to have 'javax modules' and > > >> 'jakarta modules' in the same tree for 5.x like it was for the Artemis > > >> codebase back in February 2021 when that was originally done. That > > >> made a lot of sense at the time since noone was really using them back > > >> then. Going forward, I do think having 2 versions is actually > > >> preferable, and thats what I choose to do elsewhere, and what I'd say > > >> most (but, not all) projects are doing at this later point. It does > > >> mean backporting things if supporting both, but also means a simpler > > >> build and a nicer testing situation etc, and slightly less user change > > >> (just updating the version, not knowing new -jakarta dep exists and > > >> also updating version). > > >> > > >> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jbert...@apache.org> > wrote: > > >>> > > >>> I don't have a deep familiarity with the internals here so some of > the > > >>> fundamentals behind the changes aren't clear to me. > > >>> > > >>> Is the move to JDK 17 prompted by the fact that Spring 6 requires > it? How > > >>> tightly is "Classic" coupled with Spring? > > >>> > > >>> Is the coupling with Spring also why the code-base is being moved > > >>> whole-sale to Jakarta? It's been a little while now, but when Artemis > > >>> implemented Jakarta support back in early 2021 I don't recall any > > >>> disruption for current users and no major version change was needed. > Both > > >>> Java EE and Jakarta EE implementations are based on the same > code-base. Is > > >>> something like that not possible here? It would simplify maintenance > a lot > > >>> since fixes/features wouldn't have to be back-ported. > > >>> > > >>> > > >>> Justin > > >>> > > >>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon < > > >>> christopher.l.shan...@gmail.com> wrote: > > >>> > > >>>> First, I realize that this thread is likely to cause a fight based > on past > > >>>> history and probably not go anywhere, but with the work being done > > >>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the > > >>>> ActiveMQ 6.0 discussion. > > >>>> > > >>>> With all the breaking changes currently targeted for version > 5.19.x, such > > >>>> as the Jakarta switch from javax, requiring JDK 17, major Spring > and Jetty > > >>>> upgrades and now potentially major OSGi changes, it makes zero > sense to me > > >>>> to have this next AMQ version as version 5.19.0 as it's completely > > >>>> incompatible with the previous version 5.18.x. Users are likely > going to be > > >>>> in for a rude awakening when trying to upgrade and will be quite > confused > > >>>> as to why so much is different. > > >>>> > > >>>> The Jakarta changes should really be a major version upgrade so > that it's > > >>>> much more clear to users that it's very different from the previous > > >>>> version. Another major benefit of going with version 6.0 is that it > frees > > >>>> up the previous javax releases to continue on with 5.19 or 5.20 > because we > > >>>> will likely need to support the older javax releases for quite a > while. > > >>>> > > >>>> Also, from my point of view it seems pretty clear that the original > goal > > >>>> for Artemis to become AMQ 6.0.0 is never going to happen. Artemis > has had > > >>>> its own branding and versioning for several years now and will > likely > > >>>> continue that way and not change so I don't really see that as a > reason to > > >>>> not bump AMQ 5.x to 6.x with all the major breaking changes. > > >>>> > > >>>> Anyways, I figure there won't be much agreement here but thought I > should > > >>>> at least throw it out there before we go and release 5.19.x with > such major > > >>>> breaking changes. > > >>>> > > >
