+1 to go with 5.17.0 without JMS 2.0 I think we should just wait for all the JMS 2.0 stuff for 5.18.0. We shouldn't even include the new dependency as it would be kind of confusing as it wouldn't implement anything. We can easily document that if someone wants to use the JMS 2.0 jar it's no problem to use it with excluding the 1.1. and using the new jar (I've been doing this for years) and just not call the new methods.
5.18.0 doesn't have to take years longer, it can go out whenever we want (1 month, 3 months, etc). So I think just reverting all the JMS 2.0 and rolling with the other updates makes sense. On Mon, Feb 21, 2022 at 7:58 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi guys, > > I agree about the change, and it was not what we agreed on the mailing > list. > > The initial plan for 5.17.0 about JMS 2.0 is "just" to update the > client side to support JMS 2.0 and throw UnsupportedOperationException > for JMS 2.0 specific method. > I think it's good enough for 5.17.0 to support the first JMS 2.0 round. > > More than that (client/broker side) should go in 5.18.0 IMHO. > > Regards > JB > > On Mon, Feb 21, 2022 at 1:35 PM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > > Finally doing a 5.17.0 release sounds good. > > > > That said, I dont personally think > > https://github.com/apache/activemq/pull/729 is ready for inclusion in > > a release though, even with an '-rc1' adorned version number > > previously suggested but apparently no longer planned, since even as a > > 'first phase' it is surprisingly incomplete, adding some of the JMS 2 > > 'simplified API' but not even doing much of the basic JMS 1.1 level > > functionality within it, like setting a MessageListener on a > > JMSConsumer, or creating a durable subscriber (non-shared), or > > JMSContext's acknowledge() method for doing client-ack (presumably the > > message method works though), etc. > > > > It also just seems very odd to even think about just *starting* to > > including stuff like that on main within a couple days of intending to > > do a release thats nearing being *years* in the making, and getting > > describe to users as '2-3 weeks' for way over a year now, including > > multiple times in the last few months. > > > > For me, the most obvious idea at this point would actually be for > > 5.17.x to be branched and proceed without this. Theres a load of stuff > > in it already that is long overdue like the JDK11 build etc. I would > > go so far as to say the prior API jar change from early November > > (https://github.com/apache/activemq/pull/682) should also be > > effectively reverted, it makes no sense to me on its own. Then all of > > this stuff then worked on towards a 5.18.x release that actually > > implements and tests things to a reasonable level thats less likely to > > see even trivial use cases fail to work. > > > > Robbie > > > > On Mon, 21 Feb 2022 at 04:55, 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 >
