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
