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. >>>>>>> >>> >>
