I’ve cleared my breaking change and other non-trival effort JIRAs out of 5.17.0 and over to 5.18.0.
I’ve got two minor config default changes left to finish unit tests (carry over from improvements in 5.16.4). I should have those knocked out by tonight. My other tasks are minor website fix and document example for activemq-camel removal that I can get out during the vote. Thanks, Matt Pavlovich > On Feb 23, 2022, at 10:01 AM, Matt Pavlovich <mattr...@gmail.com> wrote: > > ok, lets go > >> On Feb 23, 2022, at 9:27 AM, Christopher Shannon >> <christopher.l.shan...@gmail.com> wrote: >> >> Matt, the reason to roll back is for what Robbie just said. >> >> I know the discussion originally was that the first step of this would be >> to include the jar with no impl and just UOE. But I've been convinced >> after all the discussion the past couple weeks on this that there's no real >> point to doing so now because A) you already get the same behavior with >> including the jar yourself and B) there will be real client impl changes >> coming shortly with 5.18.0 it just makes a lot more sense to me to wait and >> include everything in 5.18.0. >> >> On Wed, Feb 23, 2022 at 9:57 AM Robbie Gemmell <robbie.gemm...@gmail.com> >> wrote: >> >>> It really doesnt make sense to include changing the API in 5.17.0 >>> without any impl, it would be very odd to retain to me, and also quite >>> misleading. It may also unnecessarily inconvenience people that have >>> previously adapted their builds to other bits including a >>> likely-different 2.0 API artifact if they needed it and excluding the >>> 1.1 api, into updating their excludes despite no impl change. It just >>> makes sense to unwind it. >>> >>> On Wed, 23 Feb 2022 at 14:30, Matt Pavlovich <mattr...@gmail.com> wrote: >>>> >>>> Hey Chris- >>>> >>>> I believe the JMS 2.0 impl is in good shape (fighting one test that >>> works-locally-fails-on-Apache-CI fun!). Given the desire to get 5.17.0 out >>> soon, I can get behind allowing more time for others to review and roll >>> with it in 5.18.0. >>>> >>>> How about keeping AMQ-7309 in 5.17.0 and go forward with your suggestion >>> of moving on to 5.18.0 with JMS 2.0, Jakarta updates, etc? AMQ-7309 is well >>> reviewed and been merged for 4 months. >>>> >>>> Thanks, >>>> Matt >>>> >>>>> On Feb 22, 2022, at 2:10 PM, Christopher Shannon < >>> christopher.l.shan...@gmail.com> wrote: >>>>> >>>>> In terms of maintenance if we get out 2.18, 2.19, etc then 2.17 can >>> just >>>>> get important fixes or be made EOL and we can move on. Long lived >>> branches >>>>> and support are not necessary if we keep up with more frequent >>> releases. >>>>> >>>>> 2.17.0 is at a logical cut off point where it's at now and I'm >>> definitely >>>>> not in favor of adding something brand new (Jakarta changes) last >>> minute >>>>> and I doubt others are either. >>>>> >>>>> So again..it's time to move on. As everyone else already seems to be in >>>>> agreement with (JB, Tim, Robbie) let's just do the release this week >>> with >>>>> the current changes and then move on to 2.18.0 with JMS 2.0, Jakarta >>>>> updates, etc. >>>>> >>>>> >>>>> On Tue, Feb 22, 2022 at 2:49 PM Matt Pavlovich <mattr...@gmail.com> >>> wrote: >>>>> >>>>>> Hey All- >>>>>> >>>>>> I get the idea that getting a JDK 11-based released is a good thing, >>> but I >>>>>> also think we should consider the jakarta alignment as part of what >>> active >>>>>> branches are supported. This is the path other projects have taken and >>>>>> helps users align things when they are assembling pieces for their >>>>>> environment >>>>>> >>>>>> If we go with the proposed plan in this thread-- we add JDK 11, but >>> do not >>>>>> move the ball forward on anything jakarta related — we add another >>> active >>>>>> branch to maintain. As log4j showed us, having a bunch of active >>> branches >>>>>> out there is a lot of work when it is time to crank out security >>> fixes. >>>>>> Additionally, keeping up with Jetty and other dependencies is going to >>>>>> become more difficult if we do not start taking steps to align JDK + >>>>>> jakarta in supported branches. >>>>>> >>>>>> I also feel that the current status of the JMS 2.0 phased >>> implementation >>>>>> is closer to done than the amount of work to revert AMQ-7309. PR-729 >>> has >>>>>> 200+ test cases and has addressed all feedback as of this morning. >>>>>> >>>>>> JMS 2.0 tested and validated: >>>>>> - All destinations (queue, topic, temp-topic, temp-queue) and all >>> message >>>>>> types (bytes, map, object, stream, and text) >>>>>> - All message property types (bytes, string, int, float, double, >>> short, >>>>>> etc.) including min+max data ranges >>>>>> - Foreign message support >>>>>> - Range checking on priority and deliveryMode >>>>>> - Topic Durable Subscriber (JMS v1.x alignment) >>>>>> >>>>>> Thank you, >>>>>> Matt Pavlovich >>>>>> >>>>>>> On Feb 22, 2022, at 8:16 AM, Jean-Baptiste Onofré <j...@nanthrax.net> >>>>>> wrote: >>>>>>> >>>>>>> I agree. >>>>>>> >>>>>>> @Matt @Robbie @Tim is it ok for you to have 5.17.0 with Spring5, >>>>>>> log4j2, JDK11 and include JMS2 in 5.18.0 that can happen quickly ? >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On Tue, Feb 22, 2022 at 3:09 PM Christopher Shannon >>>>>>> <christopher.l.shan...@gmail.com> wrote: >>>>>>>> >>>>>>>> I'm +1 on moving forward without JMS 2.0 until 5.18.0. The reality >>> is >>>>>> there is no consensus to keep it in 5.17.0. There are multiple people >>> who >>>>>> do not want to include it in 5.17.0 so it's time to move on without. >>> We >>>>>> also need to revert the commits from >>>>>> https://issues.apache.org/jira/browse/AMQ-7309 as there is no reason >>> to >>>>>> include that now. >>>>>>>> >>>>>>>> So I say go ahead with the release and vote (after wrapping things >>> up >>>>>> including reverting that AMQ-7309 JMS 2 stuff). >>>>>>>> >>>>>>>> I'm pretty tired of the back and forth and fighting over version >>>>>> numbers to be honest and just want to move on. It's not productive to >>> keep >>>>>> arguing anymore over a version...5.18.0 can literally go out whenever >>> we >>>>>> want. >>>>>>>> >>>>>>>> On Tue, Feb 22, 2022 at 8:50 AM Jean-Baptiste Onofré < >>> j...@nanthrax.net> >>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> Quick update about 5.17.0 release: >>>>>>>>> >>>>>>>>> - I fixed/squash log4j2 update PR >>>>>>>>> (https://github.com/apache/activemq/pull/662). I think it's OK >>> (I'm >>>>>>>>> waiting for the end of Jenkins). >>>>>>>>> - I'm creating Apache POM 25 update PR >>>>>>>>> - I'm creating Spring 5.3.16 update PR >>>>>>>>> >>>>>>>>> So, ActiveMQ 5.17.0 is almost ready from this standpoint. >>>>>>>>> >>>>>>>>> As I would like to start the vote asap, It would be great to act >>> about >>>>>>>>> JMS2. Do you want me to start with different options ? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> JB >>>>>>>>> >>>>>>>>> On Mon, Feb 21, 2022 at 5:55 AM Jean-Baptiste Onofré < >>> j...@nanthrax.net> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> I worked on the log4j2 update PR this weekend, fixing almost all >>> unit >>>>>>>>>> tests using a custom appender. I just have to fix the >>>>>>>>>> activemq-web-demo test and squash, and the PR will be good to be >>>>>>>>>> merged. I will do that today. >>>>>>>>>> >>>>>>>>>> Then, later today and tomorrow I will work on using jetty modules >>>>>>>>>> instead of jetty-all and update to Jetty 9.4.45. >>>>>>>>>> >>>>>>>>>> I will do a pass on Jira and PRs, especially the ones from Matt. >>> @Matt >>>>>>>>>> can you please ping me on slack to check together the status of >>> the >>>>>>>>>> PRs ? >>>>>>>>>> >>>>>>>>>> Regarding this, I would like to submit 5.17.0 to vote this >>> Thursday if >>>>>>>>>> there are no objections. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> JB >>>>>> >>>>>> >>>> >>> >
