> The problem is on 5.16.x as it changed between 5.16.2 and 5.16.3. 5.17.x is not a problem as it's "major" update.
The jump from 5.16.x to 5.17.x would traditionally be considered a "minor" update rather than a "major" one. A "major" update would be something like 5.x to 6.x. Even in the case of a major update it's still good practice to inform users of breaking changes. They won't be able to manage upgrades properly without such information. > I remember sharing this on the mailing list, so it's a pita that we have such feedback now. I've been through this with other users in the past. Ultimately I think the mailing list is insufficient for release details like this. It's common practice to document them clearly. We did this for Artemis initially via ARTEMIS-1714 [1] and updating the doc is part of the release instructions [2]. > And again, it's used in production for a while without problem. Just extending a range is not a lot of work, simple fix. As noted, if you already know how to fix it's simple. The problem is when you don't know how to fix it. That's what the documentation would ameliorate. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-1714 [2] https://github.com/apache/activemq-artemis/blob/main/RELEASING.md#a-check-list-of-things-to-be-done-before-a-release On Tue, Jun 21, 2022 at 9:14 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi, > > I think: > 1. The problem is on 5.16.x as it changed between 5.16.2 and 5.16.3. > 5.17.x is not a problem as it's "major" update. > 2. I remember sharing this on the mailing list, so it's a pita that we > have such feedback now. And again, it's used in production for a while > without problem. Just extending a range is not a lot of work, simple > fix. > > IMHO, it's not good to revert the change (it will break a lot of > clients using JMS 2.0),I would propose to add back JMS 1.1 on 5.16.x > (meaning we will have both JMS 1.1 and 2.0 bundles). > > Regards > JB > > On Tue, Jun 21, 2022 at 3:55 PM Justin Bertram <jbert...@apache.org> > wrote: > > > > Are those three options outlined in the release notes for 5.17.1? > > > > I don't want to speak for Art, but my impression is that the main problem > > here is that something which used to work is now broken. To your point, > > modifying the range is simple, but only if you *already know* that it > needs > > to be changed. Otherwise one would have to investigate the cause of the > > problem and then identify the proper solution. This could be quite a > > frustrating surprise. At the very least this should be documented in the > > release notes as a breaking change so users can know about the issue > before > > they upgrade. > > > > > > Justin > > > > On Tue, Jun 21, 2022 at 8:09 AM Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > OK, now I understand the confusion: > > > > > > Karaf activemq-client feature uses activemq-osgi bundle, not > > > activemq-client bundle. The activemq-client bundle is not used at all > > > in the Karaf features: we use the activemq-osgi uber bundle. > > > > > > So, if a user uses activemq-client bundle (without the feature), it > > > will have to install geronimo-spec-jms 1.1 bundle:but nothing changed > > > there, it's as it was before. > > > > > > Now, strictly speaking of the activemq-client karaf feature, it's fine > > > as it uses activemq-osgi bundle, with the javax.jms,version="[1.1,3)" > > > range. > > > > > > Regarding Art's issue, the problem is that activemq-client karaf > > > feature provides JMS 2.0 by default, but Art's bundle still import > > > [1.1,2) (not [1.1,3)). > > > > > > I see three options here: > > > 1. Art can fix his bundles header to use the extended range [1.1,3). > > > 2. The user who wants to still use JMS 1.1, they can stay with ActiveMQ > > > 5.15.x > > > 3. The user who wants to still use JMS 1.1, we can add geronimo-spec > > > jms 1.1 in activemq-client karaf feature, meaning that we will have > > > both JMS 1.1 and 2.0 packages at runtime. > > > > > > Honestly, why not extending the range, easy to do and it works fine > > > (it's what Karaf and Camel are using) ? > > > > > > Regards > > > JB > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 21, 2022 at 1:53 PM Jean-Baptiste Onofré <j...@nanthrax.net> > > > wrote: > > > > > > > > I tested at runtime on activemq-osgi bundle used by activemq-client. > > > > > > > > The feature verify would not work with this range. > > > > > > > > Let me take a look but I doubt it's the case. > > > > > > > > On Tue, Jun 21, 2022 at 11:53 AM Robbie Gemmell > > > > <robbie.gemm...@gmail.com> wrote: > > > > > > > > > > The javax.jms; version="[1.1,2)" value I quoted was directly from > the > > > > > Import-Package manifest entry of the 5.16.3 and 5.16.5 > activemq-client > > > > > jars on maven central. On checking 5.17.1 it lists the same. > > > > > > > > > > On Tue, 21 Jun 2022 at 09:56, Jean-Baptiste Onofré < > j...@nanthrax.net> > > > wrote: > > > > > > > > > > > > activemq-client 5.16.3 does use the right range: > > > > > > > > > > > > javax.jms;version="[1.1,3)", > > > > > > > > > > > > Else it won't work. > > > > > > > > > > > > And by the way, before the change, I sent a couple of messages > on the > > > > > > mailing list as a discussion thread. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > On Tue, Jun 21, 2022 at 10:37 AM Robbie Gemmell > > > > > > <robbie.gemm...@gmail.com> wrote: > > > > > > > > > > > > > > I believe the 5.16.x client doesnt have the below, instead > saying: > > > > > > > javax.jms; version="[1.1,2)" > > > > > > > despite the Feature only supplying the 2.0 version which > appears > > > > > > > incompatible with this. Maybe thats whats tripping Art's usage > up > > > > > > > since he was clearly using <= 5.16.2 before? > > > > > > > > > > > > > > On Tue, 21 Jun 2022 at 09:24, Jean-Baptiste Onofré < > > > j...@nanthrax.net> wrote: > > > > > > > > > > > > > > > > By the way, you can see in activemq-client: > > > > > > > > > > > > > > > > javax.jms;version="[1.1,3)", > > > > > > > > > > > > > > > > So: > > > > > > > > 1. if your application uses the same range, it works > > > > > > > > 2. if your application use [1.1,2), than, simple add > javax.jms > > > > > > > > (geronimo) 1.1 bundle > > > > > > > > > > > > > > > > Regards > > > > > > > > JB > > > > > > > > > > > > > > > > On Mon, Jun 20, 2022 at 7:45 PM Arthur Naseef < > a...@amlinv.com> > > > wrote: > > > > > > > > > > > > > > > > > > I created the following ticket to address applications > failing > > > to load into > > > > > > > > > Karaf with AMQ 5.16.3 - 5.17.1 due to an incompatible > change > > > in the > > > > > > > > > activemq-client feature. > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/AMQ-8971 > > > > > > > > > > > > > > > > > > > > > > > > > > > Looks to me like the right fix here is to revert the > change to > > > the JMS 1.1 > > > > > > > > > spec in the feature because all of the AMQ internals are > still > > > 100% on the > > > > > > > > > JMS 1.1 spec. The maven-bundle-plugin for client > applications > > > is doing the > > > > > > > > > right thing by generating "Package-Import" lines with > version > > > range > > > > > > > > > "1.1,2.0)", but the feature doesn't match it. > > > > > > > > > > > > > > > > > > It seems we have sacrificed the core case to solve an edge > > > case. > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > Art > > > > > > > >
