That is true, and if it had been done a while ago as I'd say it should have been, when 17 was far newer, thats probably the approach I'd have taken while supporting both majors (and thus both 11 and 17) for a term in order to support both JDKs.
At this late stage though, where 11 has already been twice superseded as the current LTS and is ~2/3rds of the way to being superseded again, and others have bumped years earlier, I'd be more likely to do the same as we did previously and just switch in the minor and do the new major later with the bigger changes, and then support both of those majors for a period of overlap. I dont think changing the major for essentially just the JVM version change is needed. Especially not if we are not going to continue releasing the older major, and not if we expect to do a truly actual major big-change relatively quickly after. I probably dont see us changing majors every 2 years (period of each LTS; 25 is only ~9 months from supplanting 21 as the current LTS), but I do think we should be dropping old JDKs at a similar rate as the new LTS arrivals come in. Changing Java requirements in minors is something that has and is done widely, even since semver. If it coincides with other API changes, then sure its nice to align to the major, but I dont think its necessary. I think most of the major JDK version changes for stuff I use / am familiar with actually happens in minors even now. On Thu, 5 Dec 2024 at 15:26, Christopher Shannon <christopher.l.shan...@gmail.com> wrote: > > Another option is to do an Artemis 3.0.0 release that only bumps the JDK > version to 17+ and then at some point next year just bump to 4.0.0 when > removing deprecated things like javax. There's nothing that says Artemis > 3.x has to be around for several years like 2.x before jumping to version > 4.x. > > On Thu, Dec 5, 2024 at 10:06 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
