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é w
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 mi
> 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 ad
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 servi
> The conversation shouldn’t be reductive and state ‘just a JDK rev',
because that isn’t true.
We've been talking specifically about Jetty 12 + JDK 17 from the beginning.
I don't think anybody has couched this as 'just a JDK rev.'
That said, the Jetty 12 upgrade is really an implementation detail
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
> 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 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 th
> 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'v
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
I think it makes sense to update. We could also later integrate the
new console that way too (it needs Jetty 11 or 12).
>From what I can see, ActiveMQ 6.0.0 is actually the only time in the
last ~15 years and several JDK minimum version changes where it wasnt
made in a minor version, across either
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.
O
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 a
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
> 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
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
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 wrote:
> > What version of ActiveMQ Classic are you referring to making this change
> in a minor version? v6.0.0 made the jump to
> 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 re
> On Dec 4, 2024, at 11:17 AM, Justin Bertram 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
Currently Artemis requires at least Java 11 to build and run. We moved from
Java 8 to 11 almost exactly 3 years ago in version 2.20.0 which was
released in December 2021.
I recently noticed that security fixes for Jetty 10 (which we embed) will
end in January 2025 [1]. Jetty 12 would be relatively
20 matches
Mail list logo
