Questions: Compatibility

[timonzi]

There are compatibility tables in the documentation that I'm not sure I understand correctly.

Quarkus version	Quarkus JMS version
2.x	latest 2.x
3.0.x 3.1.x 3.2.x	latest 3.0.x
3.3.x 3.4.x 3.5.x 3.6.x	3.1.x

Quarkus LTS version	Quarkus JMS version
3.2.x	3.0.x

Source: https://docs.quarkiverse.io/quarkus-artemis/dev/quarkus-artemis-jms.html#_compatibility

Does this mean, that every (patch) version of Quarkus of 3.2 is compatible with every ActiveMQ Artemis JMS starting with 3.0?

Because I saw for example that there is a new release 3.0.5, where the Quarkus version was updated from 3.2.9.Final to 3.2.10.Final. Now the question arises as to whether I also have to use the new release 3.0.5 when updating to Quarkus 3.2.10.Final!?

The second question is about the LTS: In the release 3.0.5 was updated from 2.31.2 to 2.32.0. This is strange to me, as I would not expect an update of the version in a LTS version. If I have understood correctly, the broker should normally be updated before the client (see https://stackoverflow.com/a/70623912/7171936). This means to me, that when updating from e.g. 3.0.1 (currently used version) to 3.0.5, I have a breaking change, as I have to update the brokers at first.

Or isn't the 3.0.x version considered as a LTS version and the LTS only refers to the Quarkus version?

[middagj]

Does this mean, that every (patch) version of Quarkus of 3.2 is compatible with every ActiveMQ Artemis JMS starting with 3.0?

No, this is a compatibility list of our extension "Quarkus JMS" with the Quarkus core. So every Quarkus 3.2.x is compatible with every 3.0.x of our plugin. The example you mention fits this.

As for the upgrades you mention. Basically we bump the versions of our dependencies with dependabot automatically for all our release branches. For Quarkus core it shouldn't really matter. If you list both versions explicitly you should have no problem as long as it coheres to the compatibility list. For Artemis it does matter and the general advice is (especially for production systems) it to always set the client version explicitly yourself. Best thing is to keep the client the same as the server as that gives the best assurances that it will match. So the client version we put as our dependency is just the latest and you can usually swap it for a different one and actually should do it. Perhaps we should add this to our docs.

I didn't know that Artemis themselves don't test newer clients with older servers as well as they do with older clients and newer servers. Perhaps we might want to reconsider updating Artemis client automatically on release branches for people who don't explicitly set their Artemis version. @turing85 what do you think?

[turing85]

So as far as I see it, the consumer of this extension is free to change the cocrete artemis driver, as @middagj said. As of now, the merges of the driver only happen when there are no incompatibilities detected on our end, e.g.:

• breaking changes in the client, which we would detect since the corresponding artemiscloud image always trails some days behind, so we test the new driver against the old version, or
• breaking changes in the API, which would require intervention from our side, which would then lead to a mandatory update on the client side.

I am unsure if we should stop automerging. We could probably make a minor bump when artemis makes a minor bump. but this also means that, for example, we cannot bump a minor version on an LTS branch (like 3.0.x). Would this be helpful @timonzi ? And what do you think about minor-bumping when the artemis clients minor-bumps @middagj , @zhfeng @louisa-fr ?

On a side note: I am a maintainer now for ~ 1.5 years I think. As far as I can remember, there was never a breaking change in the client as described above. So I would suspect™ that at least the client-versions of the past 1.5 years should work.

[middagj]

One of the problems is that Artemis does not have LTS releases we could tie our LTS releases to. Given the fact that Artemis is more invested in to ensure old clients can talk to new servers I would be inclined to stop auto updating for our LTS releases as it will be more stable for the casual user. But I also would recommend anyone to set their Artemis client version explicitly, and preferably the same as the server. The latter will be more resilient than relying on a random client we froze to when Quarkus decided to set a LTS release.

Like @turing85 says, we haven't seen any issues with using different clients with an extension. The one we did saw was a bug in the client (referred in the SO post you linked) which we solved upstream. Any Artemis incompatibly I would consider a bug which either needs to be fixed or documented.

[timonzi]

Best thing is to keep the client the same as the server as that gives the best assurances that it will match.

This is what we are currently doing to avoid any compatibility problems as far as possible. But that means for the moment, that we do not update the Quarkus Artemis extension so often, because of the client updates and possible (unknown) incompatibilities.

So the client version we put as our dependency is just the latest and you can usually swap it for a different one and actually should do it. Perhaps we should add this to our docs.

Do I understand you correctly that we should stick to a version that is listed as compatible with the corresponding version of Quarkus, but override the version of the client dependency itself? So by overriding your Maven property artemis.version? If I understand this correctly and its secure to do so, I would be fine with it. But the stability would really have to be ensured. And yes, it would be nice when this will be documented.

We could probably make a minor bump when artemis makes a minor bump. but this also means that, for example, we cannot bump a minor version on an LTS branch (like 3.0.x). Would this be helpful @timonzi ?

It would be absolutely fine with me if there was no update of the client version at all in a LTS release.

Because of the term "minor" bump, I'm not sure what this ultimately means. Our (!) rule is that if any action has to take place after/before an update of a component/dependency, then it is automatically a breaking change and requires a major release. So if for example the client version is raised from 2.16 to 2.19, as in the SO post, and I am forced to update the broker, then this must also be recognizable by the version number (major version update) and of course also in the release notes. But as I said, this is our rule - which is a more strict/extended definition of semantic versioning. And Artemis does not seem to use semantic versioning at all. Also I didn't found any compatibility matrix (client vs broker).

[turing85]

Overriding artemis.version in the pom.xml is not sufficient, sadly (or I am missing something; I just tired with ./mvnw dependency:tree and setting artemis.version had 0 effect). We would need to include all org.apache.activemq-dependencies, with the same excludes we do on the bom.

The more I think about it; the more I come to the conclusion that providing a separate bom just for the org.apache.activemq-dependencies may be a good idea. This bom should then be "in-sync" with the versions of org.apache.activemq. @middagj WDYT?

[middagj]

This is what we are currently doing to avoid any compatibility problems as far as possible. But that means for the moment, that we do not update the Quarkus Artemis extension so often, because of the client updates and possible (unknown) incompatibilities.

This is what I was a little bit afraid of (when mentioning the updates in the release notes), but you should not update the Quarkus extension if you just want to update Artemis. We provide the plumbing, which in general should work for multiple versions. We just improve the plumbing in the extension.

Do I understand you correctly that we should stick to a version that is listed as compatible with the corresponding version of Quarkus, but override the version of the client dependency itself? So by overriding your Maven property artemis.version? If I understand this correctly and its secure to do so, I would be fine with it. But the stability would really have to be ensured. And yes, it would be nice when this will be documented.

Yes, that is what I meant.

Overriding artemis.version in the pom.xml is not sufficient, sadly (or I am missing something; I just tired with ./mvnw dependency:tree and setting artemis.version had 0 effect). We would need to include all org.apache.activemq-dependencies, with the same excludes we do on the bom.

I think we override it with dependencyManagement in my last project.

The more I think about it; the more I come to the conclusion that providing a separate bom just for the org.apache.activemq-dependencies may be a good idea. This bom should then be "in-sync" with the versions of org.apache.activemq. @middagj WDYT?

Wouldn't that be a crossproduct of all versions? Looks like a lot of administration to me.

[turing85]

@middagj not necessarily. I mean a separate artifact, with own version. The bom would "only" include this part: https://github.com/quarkiverse/quarkus-artemis/blob/3889c218261d75c3ac9df43e7aa36d5d2a310a5a/bom/pom.xml#L53-L218

[middagj]

Ah, that is a nice idea for sure. Only a bit of work to get it done for all the versions of the past year.

[timonzi]

This is what I was a little bit afraid of (when mentioning the updates in the release notes), but you should not update the Quarkus extension if you just want to update Artemis. We provide the plumbing, which in general should work for multiple versions. We just improve the plumbing in the extension.

So far, we have mostly updated the Quarkus Artemis extension when we switched to a new Quarkus version and there was a new release of the extension that used the same Quarkus version.

We have done this in the past for the following reasons and have more or less kept it up to now:

• In the past it was not quite clear which version of the extension should be used. See also my questions #24+ and #249+
• If the Quarkus version differs (our import fromquarkus-universe-bom and your imports/dependencies on Quarkus), then all artefacts and/or POMs are downloaded in both versions during a Maven build (with an empty Maven repository, which often happens with our build pipelines). The multiple downloads are not a big problem in general, but I always wondered whether this could maybe lead to version conflicts.

So for us, the safest option was always to simply use the version of the extension that used the same Quarkus version (if available). At least I assumed the highest chance of compatibility here.

Also, I'm usually a fan of keeping versions of used dependencies/components/plugins generally up to date for various reasons (security, amount of changes that may be required in our code, etc.). But of course this has to be limited, because we don't want to force our other developers to update the broker version so often in this case (which can also involve manual migration steps). That we really need to update Artemis is rather rare.

I would therefore still like to keep updating the extension from time to time - because I also assume that the changes you have made are useful - if this does not necessarily mean that I have to update the brokers on all systems every time. If this is possibly by choosing the client to use it would be nice.

Perhaps you have a different opinion on our update strategy. I am open to all suggestions/recommendations.

[middagj]

So far, we have mostly updated the Quarkus Artemis extension when we switched to a new Quarkus version and there was a new release of the extension that used the same Quarkus version. … So for us, the safest option was always to simply use the version of the extension that used the same Quarkus version (if available). At least I assumed the highest chance of compatibility here.

We just update our dependencies if our integration tests passes, there is no special meaning of compatibility between our Quarkus extension and the Artemis client it depends on. Do realize, that the biggest compatibility gains you can get is between Core and our extension, and between the Artemis client and server.

For the Quarkus version the strategy depends on your appetite for update pace. If it is application that is developed in a sufficient high pace with a lot of integration tests, go for the latest, if not, go for a LTS release. LTS releases will get critical patches, security updates and bug fixes. For the Artemis version, I would just keep up with the broker on minor version level.

I see, I didn't answer one of your questions in the opening post.

Now the question arises as to whether I also have to use the new release 3.0.5 when updating to Quarkus 3.2.10.Final!?

No, the 3.0.x updates were only to backport some features. You should be able to use 3.0.1 with Quarkus 3.2.10.Final. But you should also be able to use 3.0.5 with Artemis 2.31.2.

Also, I'm usually a fan of keeping versions of used dependencies/components/plugins generally up to date for various reasons (security, amount of changes that may be required in our code, etc.). But of course this has to be limited, because we don't want to force our other developers to update the broker version so often in this case (which can also involve manual migration steps). That we really need to update Artemis is rather rare.

I would therefore still like to keep updating the extension from time to time - because I also assume that the changes you have made are useful - if this does not necessarily mean that I have to update the brokers on all systems every time. If this is possibly by choosing the client to use it would be nice.

Like said earlier it kind of depends on your appetite, but it makes sense to stay on LTS releases and only do patch levels. For Artemis it makes sense to limit the upgrades on the broker side. I would check the release notes and see if there is anything that demand upgrading the broker and otherwise just plan for it during the year. And let the client follow the broker. But to reiterate myself, separate your Artemis version from our extension.

[timonzi]

So to sum up (and to be sure that I understand you correctly)

• As long as we follow the compatibility table in your documentation, we should have no problems. So I can mix every 3.2.x Quarkus version with ever 3.0.x extension version.
• I should define the client version myself and independently of what you define in your pom.xml.
  • It is best to use the same version for the client and the broker.

Please correct me if there is a misunderstanding on my side.

What is not quite clear to me yet: How can I define the version of the client myself? Will you provide there something which allows an easy definition of the client version (maybe something like @turing85 suggested). Or do I have to manage the dependencies on my own (which I wouldn't like so much)?

[turing85]

So to sum up (and to be sure that I understand you correctly)

• As long as we follow the compatibility table in your documentation, we should have no problems. So I can mix every 3.2.x Quarkus version with ever 3.0.x extension version.

Yes.

• I should define the client version myself and independently of what you define in your pom.xml.

  • It is best to use the same version for the client and the broker.

Yes. Although I run the latest driver version on applications in production aganst a (I think) 2.29.x artemis broker, and it works without problems (take this as anecdotal, not as advice).

Please correct me if there is a misunderstanding on my side.

What is not quite clear to me yet: How can I define the version of the client myself? Will you provide there something which allows an easy definition of the client version (maybe something like @turing85 suggested). Or do I have to manage the dependencies on my own (which I wouldn't like so much)?

To fully and correctly override the versions, you'd need to copy this part of the bom and replace the version: https://github.com/quarkiverse/quarkus-artemis/blob/3889c218261d75c3ac9df43e7aa36d5d2a310a5a/bom/pom.xml#L53-L218

Please keep in mind that you'd need to pull-in those dependencies before you pull in quarkus-artemis. You can verify that the versions are overridden by calling ./mvnw dependency:tree and inspecting the versions of the artemis dependencies.

We haven't come to a conclusion as whether - and if so how - we provide a way to ease this process.

[timonzi]

Okay, thanks for the clarification/explanation :+1:

As for me: I would very much welcome a simpler way to overwrite the client version.

[timonzi]

Should we close this issue and create a new one for a more simple way to set the client version?

[middagj]

Yes, let's do that.