> The conversation shouldn’t be reductive and state ‘just a JDK rev', because that isn’t true.
We've been talking specifically about Jetty 12 + JDK 17 from the beginning. I don't think anybody has couched this as 'just a JDK rev.' That said, the Jetty 12 upgrade is really an implementation detail. No configuration or behavior changes will result and moving involves changing less than 50 lines of code which is mostly just swapping one method for another. There's no real structural differences. Users won't see any difference. The upgrade to Jetty 12 is not a reason, in and of itself, to bump a major version. Likewise, if upgraded to Netty 5 we wouldn't bump a major version despite the fact that it is a new major version and integral to the internal working of the broker. > Why not make a major release? Given the precedents in the wider open source Java ecosystem (not to mention within ActiveMQ itself) I think dropping support for Java 11 in a minor release is reasonable. Justin On Thu, Dec 5, 2024 at 11:35 AM Matt Pavlovich <mattr...@gmail.com> wrote: > The conversation shouldn’t be reductive and state ‘just a JDK rev', > because that isn’t true. It is a JDK update AND a major dependency update > in Jetty 12 (that is dragging the JDK requirement). > > Why not make a major release? Seems like an easy change to go to 3.x and > then slide the other work that may take longer to 4.x > > -Matt > > > On Dec 5, 2024, at 11:07 AM, Justin Bertram <jbert...@apache.org> wrote: > > > >> I think bumping JDK base requirement should be a major revision. > > > > Generally speaking I would agree with you. However, I'm not yet convinced > > in this case. > > > >> The purpose of moving towards stricter SEMVER is to make things more > > consistent for downstream users than they have been in the past. > > > > You've mentioned this move towards "stricter SEMVER" a few times on this > > list and alluded to conversations about it, but I don't recall these > > conversations. Did we reach a consensus around this? > > > > In any case, I'm not sure this is actually strict violation of semantic > > versioning. > > > >> Citing old ActiveMQ release as precedence is a flawed and biased > > argument, since we are moving away from that... > > > > I also cited Camel which dropped support for Java 8 in 3.15.0. Other > > notable examples: > > > > - Spring dropped support for Java 8 in 5.3.0. > > - Apache Maven dropped support for: > > - Java 5 in 3.3.0 > > - Java 6 in 3.5.0 > > - Java 7 in 3.9.0 > > - Hibernate ORM dropped support for Java 8 in 5.3.0. > > - Apache Flink dropped support for: > > - Java 7 in 1.4.0 > > - Java 8 in 1.17.0 > > - Apache Beam dropped support for Java 7 in 2.6.0. > > - Apache Pulsar dropped support for Java 8 in 2.8.0. > > - Quarkus dropped support for: > > - Java 8 in 1.3.0 > > - Java 11 in 2.7.0 > > - Apache Ignite dropped support for Java 8 in 2.8.0. > > - Apache NiFi dropped support for Java 7 in 1.4.0. > > - Apache CXF dropped support for: > > - Java 6 in 3.2.0 > > - Java 7 in 3.4.0 > > - Apache ZooKeeper dropped support for: > > - Java 6 in 3.5.0 > > - Java 7 in 3.6.0 > > - Netty will drop support for Java 7 & 8 in 4.2.0. > > > > I could go on, but hopefully the point is clear. Dropping support for a > > particular version of Java in a minor release is not uncommon even for > > major open source projects (even at Apache). We certainly don't want to > > make a habit of this, and it's not ideal, but I think this is a special > > circumstance where it makes sense. > > > >> ...the entire Java ecosystem is moving much faster than back in the > > ActiveMQ 5.5.x days. > > > > In my opinion this is actually an argument _for_ dropping specific Java > > version support in a minor release. Since new Java versions are being > > released more often the pressure to keep up is much greater than it was > > before and won't always align with a major release that actually makes > > sense otherwise. > > > > > > Justin > > > > > > On Thu, Dec 5, 2024 at 9:15 AM Matt Pavlovich <mattr...@gmail.com> > wrote: > > > >> I think bumping JDK base requirement should be a major revision. The > >> purpose of moving towards stricter SEMVER is to make things more > consistent > >> for downstream users than they have been in the past. > >> > >> Citing old ActiveMQ release as precedence is a flawed and biased > argument, > >> since we are moving away from that AND the entire Java ecosystem is > moving > >> much faster than back in the ActiveMQ 5.5.x days. > >> > >> Matt > >> > >>> On Dec 5, 2024, at 6:43 AM, Christopher Shannon < > >> christopher.l.shan...@gmail.com> wrote: > >>> > >>> We have definitely done it in the past (and so have other projects as > >>> noted) but just because we have done it in the past doesn't mean it > was a > >>> good idea, or should have been done. It goes against semver and it > could > >> be > >>> quite confusing for a users who may not realize the JDK requirement > >>> changed. So generally speaking, we should not be bumping the JDK > outside > >> of > >>> a major version. > >>> > >>> That being said, as you noted, we don't really have too much choice > here. > >>> Making sure Jetty is up to date and supported I think is the most > >> important > >>> thing because there's always new CVEs and January 2025 is not much > time. > >>> It's probably ok to bump the JDK at this point because ultimately I > >> figure > >>> someone is going to complain either way...either we don't bump the JDK > >>> requirement and people complain about Jetty and CVEs or we do bump it > and > >>> people complain about the JDK requirement. > >>> > >>> One thing we could do is only bump to JDK 17 for the server components > >> and > >>> at least keep the client jars compatible with JDK 11. Technically you > >> could > >>> just bump only the modules that are related to Jetty which might be > some > >>> benefit for users that run Artemis embedded and don't even start the > >>> webconsole, but at the very least keeping the clients compatible with > JDK > >>> 11 seems to make sense. This was the approach Kafka has taken with > >>> migrating where the server will require JDK 17 but the client will > still > >>> support JDK 11. > >>> > >>> If we want to go ahead and bump the JDK now then for 2.39.0 I would > think > >>> we could: > >>> > >>> 1. Document the change with a warning the best we can on the release > >>> page, email, etc so that users know of the change. > >>> 2. Only require JDK 17 for the server and keep the clients JDK 11 > >>> compatible. > >>> 3. Updating the start up/install scripts to detect if the JDK is too > >> old > >>> to print a warning/error would be good. I haven't looked at the > Artemis > >>> runs script so it might already do this. > >>> > >>> Then for a future 3.0.0 next year we could require JDK 17+ for > >> everything, > >>> clean up deprecations (drop javax entirely, etc) > >>> > >>> On Wed, Dec 4, 2024 at 4:31 PM Justin Bertram <jbert...@apache.org> > >> wrote: > >>> > >>>>> The biggest reason 5.x was not bumped was simply because of the whole > >>>> "Artemis will become version 6.0" thing that prevented the bump for a > >> long > >>>> time. > >>>> > >>>> Looking back further in the history of Classic, the Java version was > >> bumped > >>>> from 5 to 6 in 5.5.x. So there's precedent from several years before > the > >>>> donation. > >>>> > >>>>> Is there any reason we can't bump Artemis to 3.0.0? > >>>> > >>>> I think moving to 3.0.0 would be ideal, but as you note there's lots > of > >>>> other work that we'd want to do before that (e.g. dropping javax > >>>> completely, removing lots of deprecated stuff, etc.). Unfortunately I > >> don't > >>>> think there's time for that before we run afoul of the Jetty EOL, and > >> I'm > >>>> sure there's going to be folks complaining about that as soon as it > >>>> happens. > >>>> > >>>> I do think we'll see Artemis 3.0.0 relatively early in 2025, but not > >> soon > >>>> enough to mitigate this issue. > >>>> > >>>>> Requiring JDK 17 and Jetty 12 upgrade seem like a good reason for a > >> major > >>>> version bump... > >>>> > >>>> I see the Jetty 12 integration as more of an implementation detail. > >> Users > >>>> really have no way of knowing that Artemis embeds Jetty. All the > >>>> configuration obfuscates the actual implementation. None of the > >>>> functionality or configuration is changing. Therefore, I don't see > that > >> as > >>>> a compelling reason for a major version bump. > >>>> > >>>> Typically I would consider the Java upgrade a reason for a major > version > >>>> bump, but the precedents both in ActiveMQ and other projects (e.g. > >> Camel) > >>>> indicate that's not a hard and fast rule. > >>>> > >>>> > >>>> Justin > >>>> > >>>> On Wed, Dec 4, 2024 at 3:05 PM Christopher Shannon < > >>>> christopher.l.shan...@gmail.com> wrote: > >>>> > >>>>> As you said there is a precedent for it but it's probably better for > a > >>>>> major version. The biggest reason 5.x was not bumped was simply > because > >>>> of > >>>>> the whole "Artemis will become version 6.0" thing that prevented the > >> bump > >>>>> for a long time. > >>>>> > >>>>> Is there any reason we can't bump Artemis to 3.0.0? Requiring JDK 17 > >> and > >>>>> Jetty 12 upgrade seem like a good reason for a major version bump and > >> at > >>>>> the same time maybe could clean up any deprecated things hanging > >> around. > >>>>> Maybe even drop the jms client entirely and just support jakarta, > etc. > >>>>> > >>>>> It would be nice to see some of the outstanding spec issues resolved > >> like > >>>>> https://issues.apache.org/jira/browse/ARTEMIS-1262 before bumping > but > >> I > >>>>> assume that issue in particular won't ever be fixed as there is not a > >>>> good > >>>>> way to avoid breaking old clients so I don't think it's a blocker to > >> bump > >>>>> to 3.0.0. > >>>>> > >>>>> On Wed, Dec 4, 2024 at 1:04 PM Domenico Francesco Bruscino < > >>>>> bruscin...@gmail.com> wrote: > >>>>> > >>>>>> It makes sense to me because the main JDK 11 builds already ended > the > >>>>> full > >>>>>> support and are in the extended support phase. > >>>>>> > >>>>>> On Wed, 4 Dec 2024 at 18:50, Justin Bertram <jbert...@apache.org> > >>>> wrote: > >>>>>> > >>>>>>>> What version of ActiveMQ Classic are you referring to making this > >>>>>> change > >>>>>>> in a minor version? v6.0.0 made the jump to JDK 17, but 5.x did > not. > >>>>>>> > >>>>>>> To be clear, I wasn't referring specifically to the move to 17. I > was > >>>>>> just > >>>>>>> saying, in general, the move to a new version of Java has been done > >>>> in > >>>>>>> minor releases by both Artemis and Classic. I already outlined > where > >>>>> this > >>>>>>> was done by Artemis (i.e. in 2.20.0). For Classic this has been > done > >>>>>> three > >>>>>>> times: > >>>>>>> > >>>>>>> - From 5.10.x to 5.11.x the JDK went from 6 to 7 > >>>>>>> - From 5.14.x to 5.15.x the JDK went from 7 to 8 > >>>>>>> - From 5.16.x to 5.17.x the JDK went from 8 to 11 > >>>>>>> > >>>>>>> My main point here is simply that this change has a precedent in > >>>>>> ActiveMQ. > >>>>>>> There are, of course, precedents in other projects as well (e.g. > >>>>> Camel). > >>>>>>> > >>>>>>> > >>>>>>> Justin > >>>>>>> > >>>>>>> On Wed, Dec 4, 2024 at 11:40 AM Matt Pavlovich <mattr...@gmail.com > > > >>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>>> On Dec 4, 2024, at 11:17 AM, Justin Bertram <jbert...@apache.org > >>>>> > >>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> At first I was hesitant to propose this move in a minor release, > >>>>> but > >>>>>>>> then I > >>>>>>>>> realized we've already done this in both Artemis and Classic. > >>>>>>>> > >>>>>>>> Hi Justin- > >>>>>>>> > >>>>>>>> What version of ActiveMQ Classic are you referring to making this > >>>>>> change > >>>>>>>> in a minor version? v6.0.0 made the jump to JDK 17, but 5.x did > >>>> not. > >>>>>>>> > >>>>>>>> -Matt > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > >>>>>>>> For additional commands, e-mail: dev-h...@activemq.apache.org > >>>>>>>> For further information, visit: > >>>> https://activemq.apache.org/contact > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > >> For additional commands, e-mail: dev-h...@activemq.apache.org > >> For further information, visit: https://activemq.apache.org/contact > >> > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
