> I think my wider concern is solidifying SEMVER and change control as it relates to version numbers going forward.
We should have a discussion specifically about this and build consensus on a policy which we ultimately publish and follow. > ...we would be doing our users a great service if we adopted a versioning strategy that was consistent and reliable. I agree 100%. Justin On Sat, Dec 7, 2024 at 9:54 AM Matt Pavlovich <mattr...@gmail.com> wrote: > I’m +0 on this for the Artemis release. I think my wider concern is > solidifying SEMVER and change control as it relates to version numbers > going forward. > > The JDK and Jakarta EE versions are more rapidly evolving (a good thing!) > that ever in the past, so we would be doing our users a great service if we > adopted a versioning strategy that was consistent and reliable. > > Thanks, > Matt > > > On Dec 5, 2024, at 12:14 PM, Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > > I think that Robbie (and Justin) make some good points. > > > > JDK 11 is super old now and even JDK 17 is dated so it's likely not a > huge > > deal to just bump the requirement for that. Also, if we did go with a new > > major version it isn't like we'd maintain the old 2.x version because it > > would likely have an unsupported Jetty with likely CVEs anyways. Also, > that > > is a good point about testing being an issue if only the client was JDK > 11 > > so probably best to bump that too. And as Justin has noted there's > > definitely been other cases of bumping a JDK version for a minor release. > > > > So anyways, while a major version would be nice, I think it's probably ok > > just to keep it simple and go JDK 17 for 2.39.x and then next year clean > > things up for 3.0.0. JDK 17 is old enough that it shouldn't be a big > issue > > for users. Many other frameworks like Spring dropped support for JDK 11 > > already a while ago and the most important thing is to make sure we are > not > > using an old Jetty version. > > > > Going forward and to the SEMVER point, I don't know that we ever actually > > discussed fully adopting SEMVER, I know that with "classic" we are trying > > to be better at following it but I don't think anything was really voted > > on. So maybe that should be a separate discussion for how to handle these > > types of issues (ie JDK upgrades) in the futue. > > > > On Thu, Dec 5, 2024 at 12:38 PM Justin Bertram <jbert...@apache.org> > wrote: > > > >>> 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. > >> > >> I think this is essentially taken care of by the fact that all previous > >> clients will still be compatible with 2.39.0. There is no real pressure > on > >> clients to upgrade. The only client change in 2.39.0 is ARTEMIS-5093 [1] > >> and the user who wants that has already confirmed that Java 17 is not an > >> issue for them. > >> > >>> 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... > >> > >> I think that might be possible technically speaking, but it would > probably > >> get messy and ultimately confusing for users. > >> > >> > >> What would you think about just having 2 release streams (i.e. 2.x for > Java > >> 17+ and 2.39.x for Java 8+) until we get 3.0 out the door then drop > 2.39.x > >> completely and continue with critical fixes for 2.x? > >> > >> > >> Justin > >> > >> [1] https://issues.apache.org/jira/browse/ARTEMIS-5093 > >> > >> On Thu, Dec 5, 2024 at 6:49 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 > > >
