Hey Justin, So I think it's fine to go ahead with the upgrade to Jetty 12 and JDK 17+ for Artemis 2.28.0 based on this thread.
I agree we should have a discussion on SEMVER and document what we decide, I'll start a new thread on that. Chris On Mon, Dec 9, 2024 at 2:59 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi guys > > Sorry for the late reply, I was travelling last week. > > If the bump is about the JDK only, I think it's totally fine to make > it in a minor version (not a micro). I don't see why we have to be > super strict about major versions and JDK updates: a bunch of projects > bumped the JDK version on minor versions, as soon as it's clearly > stated to the users, I don't see the problem (projects can still > maintain micro versions branches). > > If we want to be super strict in terms of SEMVER, then it should be > clearly discussed and shared across the project, especially for the > users. > > So, specifically about Artemis and the JDK version, JDK versions > requirements are OK in minor versions. > > From a wider standpoint, in Classic, we agreed to have a stronger > SEMVER enforcement. If we want a global agreement about this across > ActiveMQ project, so it's fine but it should be discussed. > I think it makes sense, and we should not be scared to bump major > versions (it has a meaning for our users). For instance, we already > plan ActiveMQ Classic 7 and beyond :) > > Regards > JB > > On Mon, Dec 9, 2024 at 12:45 AM Justin Bertram <jbert...@apache.org> > wrote: > > > > > 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 > > > > > > > > > > > --------------------------------------------------------------------- > 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 > > >
