Prefer LTS releases of IBM MQ for mq-jms-spring rather than CD stream

[buznyusz]

Hi team,

I’d like to propose that for the mq-jms-spring project we adopt the Long-Term-Support (LTS) release stream of IBM MQ instead of relying on the Continuous Delivery (CD) releases.

Rationale:

According to IBM’s official FAQ, IBM MQ supports both LTS and CD release types: “LTS stands for Long Term Support … The Long Term Support release is for systems which demand the highest levels of stability … CD stands for Continuous Delivery. The CD releases add new function to MQ on a regular cadence and are intended for customers wanting to exploit the latest features …”

LTS releases are supported for a significantly longer period: “for IBM MQ software products a LTS release is supported for at least five years from the point that it is made generally available.”
https://www.ibm.com/support/pages/ibm-mq-faq-long-term-support-and-continuous-delivery-releases

By contrast, CD releases have a support window tied to the most recent two CD releases, or 12 months from general availability, whichever is longer.

The versioning document for IBM MQ further clarifies that: “Long Term Support releases always have a modification number of zero … Continuous Delivery releases usually have a modification number that is non-zero.”
https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=mq-release-types-versioning

For a client library like mq-jms-spring, which many users will adopt into production applications, alignment with the LTS stream offers stronger stability guarantees, fewer disruptive upgrades, and longer maintenance window — which in turn reduces risk for downstream applications.

Suggested change:

Update the README or project documentation of mq-jms-spring to recommend using IBM MQ LTS versions (e.g., 9.4.0.x) rather than CD patch levels (e.g., 9.4.1, 9.4.2 …) unless the user explicitly needs a new feature only available in CD.

Consider making CI/test matrix include the latest LTS version as the primary target.

Optionally: Provide guidance on how to move from CD to LTS (or vice-versa) if a user is on CD but wishes to stabilise on LTS.

Benefits:

Reduced upgrade frequency and scope (LTS focuses on fixes rather than new features).

Longer support window for production deployments (min 5 years for LTS).

Stronger backwards compatibility expectations for LTS.

Simpler versioning policy for downstream clients.

Caveats / things to consider:

If mq-jms-spring wants to adopt very latest MQ features that are only available in CD releases, you may still need to support newer CD versions — but this should be a conscious choice rather than default.

You may need to document explicitly which LTS release is supported/manually tested in your library (so users know exactly which MQ version the library has been verified with).

Migration from a CD release to an LTS release in IBM MQ may have restrictions (e.g., rollback is not supported for CD installs).
IBM

Conclusion:
Given the production-oriented nature of mq-jms-spring, I believe aligning with the LTS release stream of IBM MQ will give downstream users more confidence and reduce long-term maintenance burden.

Thanks for considering!

[ibmmqmet]

I don't think this is something I'd want to do.

From an MQ perspective, there's not really a single stable version even within the LTS stream - new fixpacks come out every few months. So we'd have to keep up with that.

And the underlying versions of Spring change with each release too, so there really is not a "stable" level there to keep at either.

If you really do want stability of all the dependencies, then you can pick one version of this package and stick there. It's not like they get deleted from Maven Central. If you only care about using an LTS level of MQ, while upgrading everything else, then it's easy to override the embedded version of MQ.

For example, in your build.gradle:

dependencies {
  implementation(group:"com.ibm.mq", name:"com.ibm.mq.jakarta.client") {
    version {  strictly "9.3.0.0"  }
  }
}

[buznyusz]

Thanks for the clarification — totally understand your point about dependency drift and Spring’s version alignment.

However, from an IBM MQ lifecycle and support policy perspective, there’s an important distinction between Continuous Delivery (CD) and Long Term Support (LTS) releases.

According to IBM’s official recommendation, LTS releases are explicitly intended for production environments where stability, predictable behavior, and long-term support are required. CD releases, on the other hand, are designed to deliver new features more frequently, but each CD build is only supported for about 12 months or two subsequent CD releases, whichever is longer.

LTS releases, such as 9.3.0 LTS or the newer 9.4.0 LTS, receive only maintenance and security fixes (no new features or breaking changes) and are supported for a minimum of five years, with optional extended support beyond that. That makes them the recommended baseline for production systems, especially in regulated or mission-critical environments.

So while it’s true that LTS fix packs are published periodically, they don’t alter the feature set or introduce compatibility risks — they just deliver cumulative security and defect fixes. This stability and long-term support commitment is precisely why IBM positions LTS as the production-grade stream.

For development or experimental purposes, CD releases are great, but for production alignment and compliance with IBM’s support model, LTS should be the default choice.

Proof:

The Long Term Support (LTS) release is a recommended product level for which support, including defect and security updates, is provided over a specified period of time.

LTS releases do not deliver new functional enhancements. They contain only defect fixes and security updates, and are made available at regular intervals. They are intended for systems that demand maximum stability over a long term deployment period. 

-- IBM MQ Documentation

A. LTS stands for Long Term Support. This corresponds with the way we supported and maintained MQ in releases earlier than 9.0. The Long Term Support release is for systems which demand the highest levels of stability - updates during the support period contain fixes to identified problems and vulnerabilities. CD stands for Continuous Delivery. The CD releases add new function to MQ on a regular cadence and are intended for customers wanting to exploit the latest features and capabilities of MQ without waiting for the next long term support release cycle. Fixes are only provided on the LTS and two most recent CD Releases.
-- IBM MQ Documentation

Organizations that run IBM MQ in production environments also typically use the LTS stream on the server side, since it’s the release line focused on maximum stability and long-term support. For that same reason, it makes sense to align the client libraries with the LTS level as well — ensuring consistent behavior, compatibility, and support alignment across the full MQ stack.

[ibmmqmet]

I fully understand the difference between the LTS and CD streams.

If you want to stick to using an LTS version of MQ, then I've already pointed out two ways you can do that.
Also look at the "Health Warning" section of the README to understand the support situation for this library itself.

I don't intend to change the default way of how this library references MQ versions.