Thanks Matt Actually, we are waiting on this one to be available for use, specifically the jakarta support and it has been a blocker for our jdk17 upgrade Can we hope for October end ? or early? or do we anticipate even beyond October?
I understand its difficult to commit, but if possible will be good to know. Regards, On Thu, Sep 21, 2023 at 7:46 PM Matt Pavlovich <mattr...@gmail.com> wrote: > Hi Jayesh- > > A few weeks. There are just a few tasks left to start the release process. > You can follow the JIRA issues here: > > https://issues.apache.org/jira/browse/AMQ-9281?filter=12352674 > > Thanks! > Matt > > > > On Sep 21, 2023, at 8:24 AM, Jayesh Vaishnav <jayeshk.vaish...@gmail.com> > wrote: > > > > 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. > >>>>>>> > >>> > >> > >
