> 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've mentioned this move towards "stricter SEMVER" a few times on this
list and alluded to conversations about it, but I don't recall these
conversations. Did we reach a consensus around this?
In any case, I'm not sure this is actually strict violation of semantic
versioning.
> Citing old ActiveMQ release as precedence is a flawed and biased
argument, since we are moving away from that...
I also cited Camel which dropped support for Java 8 in 3.15.0. Other
notable examples:
- Spring dropped support for Java 8 in 5.3.0.
- Apache Maven dropped support for:
- Java 5 in 3.3.0
- Java 6 in 3.5.0
- Java 7 in 3.9.0
- Hibernate ORM dropped support for Java 8 in 5.3.0.
- Apache Flink dropped support for:
- Java 7 in 1.4.0
- Java 8 in 1.17.0
- Apache Beam dropped support for Java 7 in 2.6.0.
- Apache Pulsar dropped support for Java 8 in 2.8.0.
- Quarkus dropped support for:
- Java 8 in 1.3.0
- Java 11 in 2.7.0
- Apache Ignite dropped support for Java 8 in 2.8.0.
- Apache NiFi dropped support for Java 7 in 1.4.0.
- Apache CXF dropped support for:
- Java 6 in 3.2.0
- Java 7 in 3.4.0
- Apache ZooKeeper dropped support for:
- Java 6 in 3.5.0
- Java 7 in 3.6.0
- Netty will drop support for Java 7 & 8 in 4.2.0.
I could go on, but hopefully the point is clear. Dropping support for a
particular version of Java in a minor release is not uncommon even for
major open source projects (even at Apache). We certainly don't want to
make a habit of this, and it's not ideal, but I think this is a special
circumstance where it makes sense.
> ...the entire Java ecosystem is moving much faster than back in the
ActiveMQ 5.5.x days.
In my opinion this is actually an argument _for_ dropping specific Java
version support in a minor release. Since new Java versions are being
released more often the pressure to keep up is much greater than it was
before and won't always align with a major release that actually makes
sense otherwise.
Justin
On Thu, Dec 5, 2024 at 9:15 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
>
>
>
