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
