[DISCUSS] ActiveMQ 6.0.0 revisited

[Christopher Shannon <ch...@gmail.com>]

First, I realize that this thread is likely to cause a fight based on past
history and probably not go anywhere, but with the work being done
with Jakarta for AMQ 5.x I think it's time to at least bring up the
ActiveMQ 6.0 discussion.

With all the breaking changes currently targeted for version 5.19.x, such
as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
upgrades and now potentially major OSGi changes, it makes zero sense to me
to have this next AMQ version as version 5.19.0 as it's completely
incompatible with the previous version 5.18.x. Users are likely going to be
in for a rude awakening when trying to upgrade and will be quite confused
as to why so much is different.

The Jakarta changes should really be a major version upgrade so that it's
much more clear to users that it's very different from the previous
version. Another major benefit of going with version 6.0 is that it frees
up the previous javax releases to continue on with 5.19 or 5.20 because we
will likely need to support the older javax releases for quite a while.

Also, from my point of view it seems pretty clear that the original goal
for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
its own branding and versioning for several years now and will likely
continue that way and not change so I don't really see that as a reason to
not bump AMQ 5.x to 6.x with all the major breaking changes.

Anyways, I figure there won't be much agreement here but thought I should
at least throw it out there before we go and release 5.19.x with such major
breaking changes.

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Johan Edstrom <se...@gmail.com>]

Huge +1 

Have just worked through a few Jakarta changes and it is a lot of things you need to change. 

Sent from my pressure cooker.

> On Sep 11, 2023, at 22:23, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> Hi,
> 
> I agree and it's actually something we likely discussed while ago
> related to renaming as for me we have two really different subprojects
> (https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
> 
> IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
> to 6.x now with Spring 6, Jakarta, and other breaking changes) and
> Artemis uses his versioning (2.x; ...).
> That's exactly why I proposed to use clear different naming for the community.
> 
> So big +1 (as happy to see this discussion again as I started similar
> while ago without success, timing is probably better now).
> 
> Regards
> JB
> 
>> On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
>> <ch...@gmail.com> wrote:
>> 
>> First, I realize that this thread is likely to cause a fight based on past
>> history and probably not go anywhere, but with the work being done
>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
>> ActiveMQ 6.0 discussion.
>> 
>> With all the breaking changes currently targeted for version 5.19.x, such
>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
>> upgrades and now potentially major OSGi changes, it makes zero sense to me
>> to have this next AMQ version as version 5.19.0 as it's completely
>> incompatible with the previous version 5.18.x. Users are likely going to be
>> in for a rude awakening when trying to upgrade and will be quite confused
>> as to why so much is different.
>> 
>> The Jakarta changes should really be a major version upgrade so that it's
>> much more clear to users that it's very different from the previous
>> version. Another major benefit of going with version 6.0 is that it frees
>> up the previous javax releases to continue on with 5.19 or 5.20 because we
>> will likely need to support the older javax releases for quite a while.
>> 
>> Also, from my point of view it seems pretty clear that the original goal
>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
>> its own branding and versioning for several years now and will likely
>> continue that way and not change so I don't really see that as a reason to
>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>> 
>> Anyways, I figure there won't be much agreement here but thought I should
>> at least throw it out there before we go and release 5.19.x with such major
>> breaking changes.

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

["Jamie G." <ja...@gmail.com>]

+1, In agreement with using the 6.x line given all the breaking changes.

On Tue, Sep 12, 2023 at 6:25 AM Robbie Gemmell <ro...@gmail.com> wrote:
>
> Have you got any work towards the linked proposals idea of refreshing
> the old 5.x docs etc on the website under its component area?
>
> On Tue, 12 Sept 2023 at 05:23, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >
> > Hi,
> >
> > I agree and it's actually something we likely discussed while ago
> > related to renaming as for me we have two really different subprojects
> > (https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
> >
> > IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
> > to 6.x now with Spring 6, Jakarta, and other breaking changes) and
> > Artemis uses his versioning (2.x; ...).
> > That's exactly why I proposed to use clear different naming for the community.
> >
> > So big +1 (as happy to see this discussion again as I started similar
> > while ago without success, timing is probably better now).
> >
> > Regards
> > JB
> >
> > On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
> > <ch...@gmail.com> wrote:
> > >
> > > First, I realize that this thread is likely to cause a fight based on past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x, such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going to be
> > > in for a rude awakening when trying to upgrade and will be quite confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it frees
> > > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a reason to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I should
> > > at least throw it out there before we go and release 5.19.x with such major
> > > breaking changes.

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

I think the main thing anyone disagreed with was your proposed Leto
name being an improvement on things as they already were/are. There
was already a dedicated area on the website even then, it just still
doesnt contain much except the download page and a 'table of contents'
documentation page that just links back out to the various 'mess' as
you put it. I dont recall anyone opposing improving things there even
without the proposed name change.

On Tue, 12 Sept 2023 at 10:03, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> As we didn’t have consensus I paused on this one. But happy to prepare a
> formal website PR with dedicated area etc.
>
> Regards
> JB
>
> Le mar. 12 sept. 2023 à 10:54, Robbie Gemmell <ro...@gmail.com> a
> écrit :
>
> > Have you got any work towards the linked proposals idea of refreshing
> > the old 5.x docs etc on the website under its component area?
> >
> > On Tue, 12 Sept 2023 at 05:23, Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> > >
> > > Hi,
> > >
> > > I agree and it's actually something we likely discussed while ago
> > > related to renaming as for me we have two really different subprojects
> > > (https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
> > >
> > > IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
> > > to 6.x now with Spring 6, Jakarta, and other breaking changes) and
> > > Artemis uses his versioning (2.x; ...).
> > > That's exactly why I proposed to use clear different naming for the
> > community.
> > >
> > > So big +1 (as happy to see this discussion again as I started similar
> > > while ago without success, timing is probably better now).
> > >
> > > Regards
> > > JB
> > >
> > > On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
> > > <ch...@gmail.com> wrote:
> > > >
> > > > First, I realize that this thread is likely to cause a fight based on
> > past
> > > > history and probably not go anywhere, but with the work being done
> > > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > > ActiveMQ 6.0 discussion.
> > > >
> > > > With all the breaking changes currently targeted for version 5.19.x,
> > such
> > > > as the Jakarta switch from javax, requiring JDK 17, major Spring and
> > Jetty
> > > > upgrades and now potentially major OSGi changes, it makes zero sense
> > to me
> > > > to have this next AMQ version as version 5.19.0 as it's completely
> > > > incompatible with the previous version 5.18.x. Users are likely going
> > to be
> > > > in for a rude awakening when trying to upgrade and will be quite
> > confused
> > > > as to why so much is different.
> > > >
> > > > The Jakarta changes should really be a major version upgrade so that
> > it's
> > > > much more clear to users that it's very different from the previous
> > > > version. Another major benefit of going with version 6.0 is that it
> > frees
> > > > up the previous javax releases to continue on with 5.19 or 5.20
> > because we
> > > > will likely need to support the older javax releases for quite a while.
> > > >
> > > > Also, from my point of view it seems pretty clear that the original
> > goal
> > > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has
> > had
> > > > its own branding and versioning for several years now and will likely
> > > > continue that way and not change so I don't really see that as a
> > reason to
> > > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > >
> > > > Anyways, I figure there won't be much agreement here but thought I
> > should
> > > > at least throw it out there before we go and release 5.19.x with such
> > major
> > > > breaking changes.
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

As we didn’t have consensus I paused on this one. But happy to prepare a
formal website PR with dedicated area etc.

Regards
JB

Le mar. 12 sept. 2023 à 10:54, Robbie Gemmell <ro...@gmail.com> a
écrit :

> Have you got any work towards the linked proposals idea of refreshing
> the old 5.x docs etc on the website under its component area?
>
> On Tue, 12 Sept 2023 at 05:23, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> > Hi,
> >
> > I agree and it's actually something we likely discussed while ago
> > related to renaming as for me we have two really different subprojects
> > (https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
> >
> > IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
> > to 6.x now with Spring 6, Jakarta, and other breaking changes) and
> > Artemis uses his versioning (2.x; ...).
> > That's exactly why I proposed to use clear different naming for the
> community.
> >
> > So big +1 (as happy to see this discussion again as I started similar
> > while ago without success, timing is probably better now).
> >
> > Regards
> > JB
> >
> > On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
> > <ch...@gmail.com> wrote:
> > >
> > > First, I realize that this thread is likely to cause a fight based on
> past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x,
> such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and
> Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense
> to me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going
> to be
> > > in for a rude awakening when trying to upgrade and will be quite
> confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that
> it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it
> frees
> > > up the previous javax releases to continue on with 5.19 or 5.20
> because we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original
> goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has
> had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a
> reason to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I
> should
> > > at least throw it out there before we go and release 5.19.x with such
> major
> > > breaking changes.
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

Have you got any work towards the linked proposals idea of refreshing
the old 5.x docs etc on the website under its component area?

On Tue, 12 Sept 2023 at 05:23, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi,
>
> I agree and it's actually something we likely discussed while ago
> related to renaming as for me we have two really different subprojects
> (https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
>
> IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
> to 6.x now with Spring 6, Jakarta, and other breaking changes) and
> Artemis uses his versioning (2.x; ...).
> That's exactly why I proposed to use clear different naming for the community.
>
> So big +1 (as happy to see this discussion again as I started similar
> while ago without success, timing is probably better now).
>
> Regards
> JB
>
> On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > First, I realize that this thread is likely to cause a fight based on past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such major
> > breaking changes.

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

I agree and it's actually something we likely discussed while ago
related to renaming as for me we have two really different subprojects
(https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).

IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
to 6.x now with Spring 6, Jakarta, and other breaking changes) and
Artemis uses his versioning (2.x; ...).
That's exactly why I proposed to use clear different naming for the community.

So big +1 (as happy to see this discussion again as I started similar
while ago without success, timing is probably better now).

Regards
JB

On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
<ch...@gmail.com> wrote:
>
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[David Blevins <da...@gmail.com>]

Huge +1 for an ActiveMQ 6.0.

Great to see this discussion.


-David


> On Sep 11, 2023, at 2:14 PM, Christopher Shannon <ch...@gmail.com> wrote:
> 
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
> 
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
> 
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
> 
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
> 
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jeff Genender <jg...@apache.org>]

Its funny you mentioned this...I was just having a side discussion about this with some others and I fully agree with you.  This is a major change... as in break stuff change.  I fully agree it should be considered 6.0.  We really don't have a reservation system for number (IMHO).  I dont have any issue with Artemis potentially being 7.0 when that decision is made.  I think its extremely prudent to make AMQ 6.0 be this breaking change.

Thank you for beating to the punch on this and bringing it up.  I was very close to writing a similar email as you.

+1 for making the jakarta stuff 6.0.

Jeff


On 2023/09/11 21:14:29 Christopher Shannon wrote:
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
> 
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
> 
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
> 
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
> 
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.
> 

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

The main change is JDK17 required by the update to Spring 6.x, this is
actually the update that implies a new version (ActiveMQ is coupled to
Spring right now).

About jakarta, even on Artemis, I guess you had an impact for the
users as you moved client from javax.jms to jakarta.jms, right ?
Broker side, it's transparent for users, but not client side imho.

Regards
JB

On Thu, Sep 14, 2023 at 5:15 PM Justin Bertram <jb...@apache.org> wrote:
>
> I don't have a deep familiarity with the internals here so some of the
> fundamentals behind the changes aren't clear to me.
>
> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> tightly is "Classic" coupled with Spring?
>
> Is the coupling with Spring also why the code-base is being moved
> whole-sale to Jakarta? It's been a little while now, but when Artemis
> implemented Jakarta support back in early 2021 I don't recall any
> disruption for current users and no major version change was needed. Both
> Java EE and Jakarta EE implementations are based on the same code-base. Is
> something like that not possible here? It would simplify maintenance a lot
> since fixes/features wouldn't have to be back-ported.
>
>
> Justin
>
> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > First, I realize that this thread is likely to cause a fight based on past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such major
> > breaking changes.
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

Yep, I dont think anyone ever seriously considered classifiers for
this for reasons like that, only the converted (inc deps) separate
modules like ActiveMQ 5.18.x and Artemis have, or different versions.

On Thu, 14 Sept 2023 at 19:10, David Blevins <da...@gmail.com> wrote:
>
> Agree.  I'll also note that projects that support both namespaces and use a classifier like "-jakarta" are very hard to use if you want the "-jakarta" version.
>
> We did that in TomEE, Johnzon, OpenWebBeans, etc. and the problem is the maven pom is basically unusable to jakarta users.  Those user's had to tediously exclude all the javax dependencies and meticulously add all the right "jakarta" dependencies.
>
> It's not the greatest user experience.  Eventually we started just switching over in source and focused the poms on jakarta dependencies.
>
> -David
>
> > On Sep 14, 2023, at 8:57 AM, Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> > broker side and also uses the same classes as the client for various
> > stuff, so it has to be fully converted so you can use broker + client
> > in the same application/test without resorting to containers etc. The
> > 5.x javax broker and jakarta client simply cant be used in the same
> > classloader.
> >
> > 5.x also uses Spring for various bits and a jakarta conversion means
> > using Spring 6, which requires Java 17 as you noted (related aside: 17
> > wont be the current LTS as of next week, with Java 21
> > releasing...which has effectively been finalised for a month now since
> > there was no RC2).
> >
> > So essentially it is not as simple to have 'javax modules' and
> > 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> > codebase back in February 2021 when that was originally done. That
> > made a lot of sense at the time since noone was really using them back
> > then. Going forward, I do think having 2 versions is actually
> > preferable, and thats what I choose to do elsewhere, and what I'd say
> > most (but, not all) projects are doing at this later point. It does
> > mean backporting things if supporting both, but also means a simpler
> > build and a nicer testing situation etc, and slightly less user change
> > (just updating the version, not knowing new -jakarta dep exists and
> > also updating version).
> >
> > On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org> wrote:
> >>
> >> I don't have a deep familiarity with the internals here so some of the
> >> fundamentals behind the changes aren't clear to me.
> >>
> >> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> >> tightly is "Classic" coupled with Spring?
> >>
> >> Is the coupling with Spring also why the code-base is being moved
> >> whole-sale to Jakarta? It's been a little while now, but when Artemis
> >> implemented Jakarta support back in early 2021 I don't recall any
> >> disruption for current users and no major version change was needed. Both
> >> Java EE and Jakarta EE implementations are based on the same code-base. Is
> >> something like that not possible here? It would simplify maintenance a lot
> >> since fixes/features wouldn't have to be back-ported.
> >>
> >>
> >> Justin
> >>
> >> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> >> christopher.l.shannon@gmail.com> wrote:
> >>
> >>> First, I realize that this thread is likely to cause a fight based on past
> >>> history and probably not go anywhere, but with the work being done
> >>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> >>> ActiveMQ 6.0 discussion.
> >>>
> >>> With all the breaking changes currently targeted for version 5.19.x, such
> >>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> >>> upgrades and now potentially major OSGi changes, it makes zero sense to me
> >>> to have this next AMQ version as version 5.19.0 as it's completely
> >>> incompatible with the previous version 5.18.x. Users are likely going to be
> >>> in for a rude awakening when trying to upgrade and will be quite confused
> >>> as to why so much is different.
> >>>
> >>> The Jakarta changes should really be a major version upgrade so that it's
> >>> much more clear to users that it's very different from the previous
> >>> version. Another major benefit of going with version 6.0 is that it frees
> >>> up the previous javax releases to continue on with 5.19 or 5.20 because we
> >>> will likely need to support the older javax releases for quite a while.
> >>>
> >>> Also, from my point of view it seems pretty clear that the original goal
> >>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> >>> its own branding and versioning for several years now and will likely
> >>> continue that way and not change so I don't really see that as a reason to
> >>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> >>>
> >>> Anyways, I figure there won't be much agreement here but thought I should
> >>> at least throw it out there before we go and release 5.19.x with such major
> >>> breaking changes.
> >>>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[David Blevins <da...@gmail.com>]

Agree.  I'll also note that projects that support both namespaces and use a classifier like "-jakarta" are very hard to use if you want the "-jakarta" version.

We did that in TomEE, Johnzon, OpenWebBeans, etc. and the problem is the maven pom is basically unusable to jakarta users.  Those user's had to tediously exclude all the javax dependencies and meticulously add all the right "jakarta" dependencies.

It's not the greatest user experience.  Eventually we started just switching over in source and focused the poms on jakarta dependencies.

-David

> On Sep 14, 2023, at 8:57 AM, Robbie Gemmell <ro...@gmail.com> wrote:
> 
> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> broker side and also uses the same classes as the client for various
> stuff, so it has to be fully converted so you can use broker + client
> in the same application/test without resorting to containers etc. The
> 5.x javax broker and jakarta client simply cant be used in the same
> classloader.
> 
> 5.x also uses Spring for various bits and a jakarta conversion means
> using Spring 6, which requires Java 17 as you noted (related aside: 17
> wont be the current LTS as of next week, with Java 21
> releasing...which has effectively been finalised for a month now since
> there was no RC2).
> 
> So essentially it is not as simple to have 'javax modules' and
> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> codebase back in February 2021 when that was originally done. That
> made a lot of sense at the time since noone was really using them back
> then. Going forward, I do think having 2 versions is actually
> preferable, and thats what I choose to do elsewhere, and what I'd say
> most (but, not all) projects are doing at this later point. It does
> mean backporting things if supporting both, but also means a simpler
> build and a nicer testing situation etc, and slightly less user change
> (just updating the version, not knowing new -jakarta dep exists and
> also updating version).
> 
> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org> wrote:
>> 
>> I don't have a deep familiarity with the internals here so some of the
>> fundamentals behind the changes aren't clear to me.
>> 
>> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
>> tightly is "Classic" coupled with Spring?
>> 
>> Is the coupling with Spring also why the code-base is being moved
>> whole-sale to Jakarta? It's been a little while now, but when Artemis
>> implemented Jakarta support back in early 2021 I don't recall any
>> disruption for current users and no major version change was needed. Both
>> Java EE and Jakarta EE implementations are based on the same code-base. Is
>> something like that not possible here? It would simplify maintenance a lot
>> since fixes/features wouldn't have to be back-ported.
>> 
>> 
>> Justin
>> 
>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
>> christopher.l.shannon@gmail.com> wrote:
>> 
>>> First, I realize that this thread is likely to cause a fight based on past
>>> history and probably not go anywhere, but with the work being done
>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
>>> ActiveMQ 6.0 discussion.
>>> 
>>> With all the breaking changes currently targeted for version 5.19.x, such
>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
>>> to have this next AMQ version as version 5.19.0 as it's completely
>>> incompatible with the previous version 5.18.x. Users are likely going to be
>>> in for a rude awakening when trying to upgrade and will be quite confused
>>> as to why so much is different.
>>> 
>>> The Jakarta changes should really be a major version upgrade so that it's
>>> much more clear to users that it's very different from the previous
>>> version. Another major benefit of going with version 6.0 is that it frees
>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
>>> will likely need to support the older javax releases for quite a while.
>>> 
>>> Also, from my point of view it seems pretty clear that the original goal
>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
>>> its own branding and versioning for several years now and will likely
>>> continue that way and not change so I don't really see that as a reason to
>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>>> 
>>> Anyways, I figure there won't be much agreement here but thought I should
>>> at least throw it out there before we go and release 5.19.x with such major
>>> breaking changes.
>>> 

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jayesh Vaishnav <ja...@gmail.com>]

Thanks Matt

Actually, we are waiting on this one to be available for use, specifically
the jakarta support and it has been a blocker for our jdk17 upgrade
Can we hope for October end ? or early? or do we anticipate even beyond
October?

I understand its difficult to commit, but if possible will be good to know.

Regards,

On Thu, Sep 21, 2023 at 7:46 PM Matt Pavlovich <ma...@gmail.com> wrote:

> Hi Jayesh-
>
> A few weeks. There are just a few tasks left to start the release process.
> You can follow the JIRA issues here:
>
> https://issues.apache.org/jira/browse/AMQ-9281?filter=12352674
>
> Thanks!
> Matt
>
>
> > On Sep 21, 2023, at 8:24 AM, Jayesh Vaishnav <ja...@gmail.com>
> wrote:
> >
> > Hello,
> >
> > Any tentative timeline about when we can expect 6.0.0 to be available for
> > use
> >
> > Regards,
> > Jayeshkumar
> >
> > On Sun, 17 Sept, 2023, 10:12 pm Jean-Baptiste Onofré, <jb...@nanthrax.net>
> > wrote:
> >
> >> Hi all,
> >>
> >> I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including
> >> schemas update, etc).
> >>
> >> I will now move forward on the related changes.
> >>
> >> Thanks all,
> >> Regards
> >> JB
> >>
> >> On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich <ma...@gmail.com>
> wrote:
> >>>
> >>> Sounds good, makes sense.
> >>>
> >>> Thanks,
> >>> Matt
> >>>
> >>>> On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> wrote:
> >>>>
> >>>> I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
> >>>> changes to jakarta.jms.
> >>>>
> >>>> So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
> >>>> If users want to still use javax.jms then they will use ActiveMQ 5.x,
> >>>> if they want to use jakarta.jms, they will use ActiveMQ 6.x.
> >>>>
> >>>> It's clear like this imho.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <
> >> robbie.gemmell@gmail.com> wrote:
> >>>>>
> >>>>> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on
> the
> >>>>> broker side and also uses the same classes as the client for various
> >>>>> stuff, so it has to be fully converted so you can use broker + client
> >>>>> in the same application/test without resorting to containers etc. The
> >>>>> 5.x javax broker and jakarta client simply cant be used in the same
> >>>>> classloader.
> >>>>>
> >>>>> 5.x also uses Spring for various bits and a jakarta conversion means
> >>>>> using Spring 6, which requires Java 17 as you noted (related aside:
> 17
> >>>>> wont be the current LTS as of next week, with Java 21
> >>>>> releasing...which has effectively been finalised for a month now
> since
> >>>>> there was no RC2).
> >>>>>
> >>>>> So essentially it is not as simple to have 'javax modules' and
> >>>>> 'jakarta modules' in the same tree for 5.x like it was for the
> Artemis
> >>>>> codebase back in February 2021 when that was originally done. That
> >>>>> made a lot of sense at the time since noone was really using them
> back
> >>>>> then. Going forward, I do think having 2 versions is actually
> >>>>> preferable, and thats what I choose to do elsewhere, and what I'd say
> >>>>> most (but, not all) projects are doing at this later point. It does
> >>>>> mean backporting things if supporting both, but also means a simpler
> >>>>> build and a nicer testing situation etc, and slightly less user
> change
> >>>>> (just updating the version, not knowing new -jakarta dep exists and
> >>>>> also updating version).
> >>>>>
> >>>>> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org>
> >> wrote:
> >>>>>>
> >>>>>> I don't have a deep familiarity with the internals here so some of
> >> the
> >>>>>> fundamentals behind the changes aren't clear to me.
> >>>>>>
> >>>>>> Is the move to JDK 17 prompted by the fact that Spring 6 requires
> >> it? How
> >>>>>> tightly is "Classic" coupled with Spring?
> >>>>>>
> >>>>>> Is the coupling with Spring also why the code-base is being moved
> >>>>>> whole-sale to Jakarta? It's been a little while now, but when
> Artemis
> >>>>>> implemented Jakarta support back in early 2021 I don't recall any
> >>>>>> disruption for current users and no major version change was needed.
> >> Both
> >>>>>> Java EE and Jakarta EE implementations are based on the same
> >> code-base. Is
> >>>>>> something like that not possible here? It would simplify maintenance
> >> a lot
> >>>>>> since fixes/features wouldn't have to be back-ported.
> >>>>>>
> >>>>>>
> >>>>>> Justin
> >>>>>>
> >>>>>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> >>>>>> christopher.l.shannon@gmail.com> wrote:
> >>>>>>
> >>>>>>> First, I realize that this thread is likely to cause a fight based
> >> on past
> >>>>>>> history and probably not go anywhere, but with the work being done
> >>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> >>>>>>> ActiveMQ 6.0 discussion.
> >>>>>>>
> >>>>>>> With all the breaking changes currently targeted for version
> >> 5.19.x, such
> >>>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring
> >> and Jetty
> >>>>>>> upgrades and now potentially major OSGi changes, it makes zero
> >> sense to me
> >>>>>>> to have this next AMQ version as version 5.19.0 as it's completely
> >>>>>>> incompatible with the previous version 5.18.x. Users are likely
> >> going to be
> >>>>>>> in for a rude awakening when trying to upgrade and will be quite
> >> confused
> >>>>>>> as to why so much is different.
> >>>>>>>
> >>>>>>> The Jakarta changes should really be a major version upgrade so
> >> that it's
> >>>>>>> much more clear to users that it's very different from the previous
> >>>>>>> version. Another major benefit of going with version 6.0 is that it
> >> frees
> >>>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> >> because we
> >>>>>>> will likely need to support the older javax releases for quite a
> >> while.
> >>>>>>>
> >>>>>>> Also, from my point of view it seems pretty clear that the original
> >> goal
> >>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis
> >> has had
> >>>>>>> its own branding and versioning for several years now and will
> >> likely
> >>>>>>> continue that way and not change so I don't really see that as a
> >> reason to
> >>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> >>>>>>>
> >>>>>>> Anyways, I figure there won't be much agreement here but thought I
> >> should
> >>>>>>> at least throw it out there before we go and release 5.19.x with
> >> such major
> >>>>>>> breaking changes.
> >>>>>>>
> >>>
> >>
>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Matt Pavlovich <ma...@gmail.com>]

Hi Jayesh-

A few weeks. There are just a few tasks left to start the release process. You can follow the JIRA issues here:

https://issues.apache.org/jira/browse/AMQ-9281?filter=12352674

Thanks!
Matt


> On Sep 21, 2023, at 8:24 AM, Jayesh Vaishnav <ja...@gmail.com> wrote:
> 
> Hello,
> 
> Any tentative timeline about when we can expect 6.0.0 to be available for
> use
> 
> Regards,
> Jayeshkumar
> 
> On Sun, 17 Sept, 2023, 10:12 pm Jean-Baptiste Onofré, <jb...@nanthrax.net>
> wrote:
> 
>> Hi all,
>> 
>> I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including
>> schemas update, etc).
>> 
>> I will now move forward on the related changes.
>> 
>> Thanks all,
>> Regards
>> JB
>> 
>> On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich <ma...@gmail.com> wrote:
>>> 
>>> Sounds good, makes sense.
>>> 
>>> Thanks,
>>> Matt
>>> 
>>>> On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>> 
>>>> I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
>>>> changes to jakarta.jms.
>>>> 
>>>> So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
>>>> If users want to still use javax.jms then they will use ActiveMQ 5.x,
>>>> if they want to use jakarta.jms, they will use ActiveMQ 6.x.
>>>> 
>>>> It's clear like this imho.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <
>> robbie.gemmell@gmail.com> wrote:
>>>>> 
>>>>> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
>>>>> broker side and also uses the same classes as the client for various
>>>>> stuff, so it has to be fully converted so you can use broker + client
>>>>> in the same application/test without resorting to containers etc. The
>>>>> 5.x javax broker and jakarta client simply cant be used in the same
>>>>> classloader.
>>>>> 
>>>>> 5.x also uses Spring for various bits and a jakarta conversion means
>>>>> using Spring 6, which requires Java 17 as you noted (related aside: 17
>>>>> wont be the current LTS as of next week, with Java 21
>>>>> releasing...which has effectively been finalised for a month now since
>>>>> there was no RC2).
>>>>> 
>>>>> So essentially it is not as simple to have 'javax modules' and
>>>>> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
>>>>> codebase back in February 2021 when that was originally done. That
>>>>> made a lot of sense at the time since noone was really using them back
>>>>> then. Going forward, I do think having 2 versions is actually
>>>>> preferable, and thats what I choose to do elsewhere, and what I'd say
>>>>> most (but, not all) projects are doing at this later point. It does
>>>>> mean backporting things if supporting both, but also means a simpler
>>>>> build and a nicer testing situation etc, and slightly less user change
>>>>> (just updating the version, not knowing new -jakarta dep exists and
>>>>> also updating version).
>>>>> 
>>>>> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org>
>> wrote:
>>>>>> 
>>>>>> I don't have a deep familiarity with the internals here so some of
>> the
>>>>>> fundamentals behind the changes aren't clear to me.
>>>>>> 
>>>>>> Is the move to JDK 17 prompted by the fact that Spring 6 requires
>> it? How
>>>>>> tightly is "Classic" coupled with Spring?
>>>>>> 
>>>>>> Is the coupling with Spring also why the code-base is being moved
>>>>>> whole-sale to Jakarta? It's been a little while now, but when Artemis
>>>>>> implemented Jakarta support back in early 2021 I don't recall any
>>>>>> disruption for current users and no major version change was needed.
>> Both
>>>>>> Java EE and Jakarta EE implementations are based on the same
>> code-base. Is
>>>>>> something like that not possible here? It would simplify maintenance
>> a lot
>>>>>> since fixes/features wouldn't have to be back-ported.
>>>>>> 
>>>>>> 
>>>>>> Justin
>>>>>> 
>>>>>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
>>>>>> christopher.l.shannon@gmail.com> wrote:
>>>>>> 
>>>>>>> First, I realize that this thread is likely to cause a fight based
>> on past
>>>>>>> history and probably not go anywhere, but with the work being done
>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
>>>>>>> ActiveMQ 6.0 discussion.
>>>>>>> 
>>>>>>> With all the breaking changes currently targeted for version
>> 5.19.x, such
>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring
>> and Jetty
>>>>>>> upgrades and now potentially major OSGi changes, it makes zero
>> sense to me
>>>>>>> to have this next AMQ version as version 5.19.0 as it's completely
>>>>>>> incompatible with the previous version 5.18.x. Users are likely
>> going to be
>>>>>>> in for a rude awakening when trying to upgrade and will be quite
>> confused
>>>>>>> as to why so much is different.
>>>>>>> 
>>>>>>> The Jakarta changes should really be a major version upgrade so
>> that it's
>>>>>>> much more clear to users that it's very different from the previous
>>>>>>> version. Another major benefit of going with version 6.0 is that it
>> frees
>>>>>>> up the previous javax releases to continue on with 5.19 or 5.20
>> because we
>>>>>>> will likely need to support the older javax releases for quite a
>> while.
>>>>>>> 
>>>>>>> Also, from my point of view it seems pretty clear that the original
>> goal
>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis
>> has had
>>>>>>> its own branding and versioning for several years now and will
>> likely
>>>>>>> continue that way and not change so I don't really see that as a
>> reason to
>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>>>>>>> 
>>>>>>> Anyways, I figure there won't be much agreement here but thought I
>> should
>>>>>>> at least throw it out there before we go and release 5.19.x with
>> such major
>>>>>>> breaking changes.
>>>>>>> 
>>> 
>> 

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jayesh Vaishnav <ja...@gmail.com>]

Hello,

Any tentative timeline about when we can expect 6.0.0 to be available for
use

Regards,
Jayeshkumar

On Sun, 17 Sept, 2023, 10:12 pm Jean-Baptiste Onofré, <jb...@nanthrax.net>
wrote:

> Hi all,
>
> I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including
> schemas update, etc).
>
> I will now move forward on the related changes.
>
> Thanks all,
> Regards
> JB
>
> On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich <ma...@gmail.com> wrote:
> >
> > Sounds good, makes sense.
> >
> > Thanks,
> > Matt
> >
> > > On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> > >
> > > I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
> > > changes to jakarta.jms.
> > >
> > > So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
> > > If users want to still use javax.jms then they will use ActiveMQ 5.x,
> > > if they want to use jakarta.jms, they will use ActiveMQ 6.x.
> > >
> > > It's clear like this imho.
> > >
> > > Regards
> > > JB
> > >
> > > On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <
> robbie.gemmell@gmail.com> wrote:
> > >>
> > >> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> > >> broker side and also uses the same classes as the client for various
> > >> stuff, so it has to be fully converted so you can use broker + client
> > >> in the same application/test without resorting to containers etc. The
> > >> 5.x javax broker and jakarta client simply cant be used in the same
> > >> classloader.
> > >>
> > >> 5.x also uses Spring for various bits and a jakarta conversion means
> > >> using Spring 6, which requires Java 17 as you noted (related aside: 17
> > >> wont be the current LTS as of next week, with Java 21
> > >> releasing...which has effectively been finalised for a month now since
> > >> there was no RC2).
> > >>
> > >> So essentially it is not as simple to have 'javax modules' and
> > >> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> > >> codebase back in February 2021 when that was originally done. That
> > >> made a lot of sense at the time since noone was really using them back
> > >> then. Going forward, I do think having 2 versions is actually
> > >> preferable, and thats what I choose to do elsewhere, and what I'd say
> > >> most (but, not all) projects are doing at this later point. It does
> > >> mean backporting things if supporting both, but also means a simpler
> > >> build and a nicer testing situation etc, and slightly less user change
> > >> (just updating the version, not knowing new -jakarta dep exists and
> > >> also updating version).
> > >>
> > >> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org>
> wrote:
> > >>>
> > >>> I don't have a deep familiarity with the internals here so some of
> the
> > >>> fundamentals behind the changes aren't clear to me.
> > >>>
> > >>> Is the move to JDK 17 prompted by the fact that Spring 6 requires
> it? How
> > >>> tightly is "Classic" coupled with Spring?
> > >>>
> > >>> Is the coupling with Spring also why the code-base is being moved
> > >>> whole-sale to Jakarta? It's been a little while now, but when Artemis
> > >>> implemented Jakarta support back in early 2021 I don't recall any
> > >>> disruption for current users and no major version change was needed.
> Both
> > >>> Java EE and Jakarta EE implementations are based on the same
> code-base. Is
> > >>> something like that not possible here? It would simplify maintenance
> a lot
> > >>> since fixes/features wouldn't have to be back-ported.
> > >>>
> > >>>
> > >>> Justin
> > >>>
> > >>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> > >>> christopher.l.shannon@gmail.com> wrote:
> > >>>
> > >>>> First, I realize that this thread is likely to cause a fight based
> on past
> > >>>> history and probably not go anywhere, but with the work being done
> > >>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > >>>> ActiveMQ 6.0 discussion.
> > >>>>
> > >>>> With all the breaking changes currently targeted for version
> 5.19.x, such
> > >>>> as the Jakarta switch from javax, requiring JDK 17, major Spring
> and Jetty
> > >>>> upgrades and now potentially major OSGi changes, it makes zero
> sense to me
> > >>>> to have this next AMQ version as version 5.19.0 as it's completely
> > >>>> incompatible with the previous version 5.18.x. Users are likely
> going to be
> > >>>> in for a rude awakening when trying to upgrade and will be quite
> confused
> > >>>> as to why so much is different.
> > >>>>
> > >>>> The Jakarta changes should really be a major version upgrade so
> that it's
> > >>>> much more clear to users that it's very different from the previous
> > >>>> version. Another major benefit of going with version 6.0 is that it
> frees
> > >>>> up the previous javax releases to continue on with 5.19 or 5.20
> because we
> > >>>> will likely need to support the older javax releases for quite a
> while.
> > >>>>
> > >>>> Also, from my point of view it seems pretty clear that the original
> goal
> > >>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis
> has had
> > >>>> its own branding and versioning for several years now and will
> likely
> > >>>> continue that way and not change so I don't really see that as a
> reason to
> > >>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >>>>
> > >>>> Anyways, I figure there won't be much agreement here but thought I
> should
> > >>>> at least throw it out there before we go and release 5.19.x with
> such major
> > >>>> breaking changes.
> > >>>>
> >
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi all,

I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including
schemas update, etc).

I will now move forward on the related changes.

Thanks all,
Regards
JB

On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich <ma...@gmail.com> wrote:
>
> Sounds good, makes sense.
>
> Thanks,
> Matt
>
> > On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >
> > I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
> > changes to jakarta.jms.
> >
> > So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
> > If users want to still use javax.jms then they will use ActiveMQ 5.x,
> > if they want to use jakarta.jms, they will use ActiveMQ 6.x.
> >
> > It's clear like this imho.
> >
> > Regards
> > JB
> >
> > On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <ro...@gmail.com> wrote:
> >>
> >> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> >> broker side and also uses the same classes as the client for various
> >> stuff, so it has to be fully converted so you can use broker + client
> >> in the same application/test without resorting to containers etc. The
> >> 5.x javax broker and jakarta client simply cant be used in the same
> >> classloader.
> >>
> >> 5.x also uses Spring for various bits and a jakarta conversion means
> >> using Spring 6, which requires Java 17 as you noted (related aside: 17
> >> wont be the current LTS as of next week, with Java 21
> >> releasing...which has effectively been finalised for a month now since
> >> there was no RC2).
> >>
> >> So essentially it is not as simple to have 'javax modules' and
> >> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> >> codebase back in February 2021 when that was originally done. That
> >> made a lot of sense at the time since noone was really using them back
> >> then. Going forward, I do think having 2 versions is actually
> >> preferable, and thats what I choose to do elsewhere, and what I'd say
> >> most (but, not all) projects are doing at this later point. It does
> >> mean backporting things if supporting both, but also means a simpler
> >> build and a nicer testing situation etc, and slightly less user change
> >> (just updating the version, not knowing new -jakarta dep exists and
> >> also updating version).
> >>
> >> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org> wrote:
> >>>
> >>> I don't have a deep familiarity with the internals here so some of the
> >>> fundamentals behind the changes aren't clear to me.
> >>>
> >>> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> >>> tightly is "Classic" coupled with Spring?
> >>>
> >>> Is the coupling with Spring also why the code-base is being moved
> >>> whole-sale to Jakarta? It's been a little while now, but when Artemis
> >>> implemented Jakarta support back in early 2021 I don't recall any
> >>> disruption for current users and no major version change was needed. Both
> >>> Java EE and Jakarta EE implementations are based on the same code-base. Is
> >>> something like that not possible here? It would simplify maintenance a lot
> >>> since fixes/features wouldn't have to be back-ported.
> >>>
> >>>
> >>> Justin
> >>>
> >>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> >>> christopher.l.shannon@gmail.com> wrote:
> >>>
> >>>> First, I realize that this thread is likely to cause a fight based on past
> >>>> history and probably not go anywhere, but with the work being done
> >>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> >>>> ActiveMQ 6.0 discussion.
> >>>>
> >>>> With all the breaking changes currently targeted for version 5.19.x, such
> >>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> >>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
> >>>> to have this next AMQ version as version 5.19.0 as it's completely
> >>>> incompatible with the previous version 5.18.x. Users are likely going to be
> >>>> in for a rude awakening when trying to upgrade and will be quite confused
> >>>> as to why so much is different.
> >>>>
> >>>> The Jakarta changes should really be a major version upgrade so that it's
> >>>> much more clear to users that it's very different from the previous
> >>>> version. Another major benefit of going with version 6.0 is that it frees
> >>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
> >>>> will likely need to support the older javax releases for quite a while.
> >>>>
> >>>> Also, from my point of view it seems pretty clear that the original goal
> >>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> >>>> its own branding and versioning for several years now and will likely
> >>>> continue that way and not change so I don't really see that as a reason to
> >>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> >>>>
> >>>> Anyways, I figure there won't be much agreement here but thought I should
> >>>> at least throw it out there before we go and release 5.19.x with such major
> >>>> breaking changes.
> >>>>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Matt Pavlovich <ma...@gmail.com>]

Sounds good, makes sense.

Thanks,
Matt

> On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
> changes to jakarta.jms.
> 
> So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
> If users want to still use javax.jms then they will use ActiveMQ 5.x,
> if they want to use jakarta.jms, they will use ActiveMQ 6.x.
> 
> It's clear like this imho.
> 
> Regards
> JB
> 
> On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <ro...@gmail.com> wrote:
>> 
>> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
>> broker side and also uses the same classes as the client for various
>> stuff, so it has to be fully converted so you can use broker + client
>> in the same application/test without resorting to containers etc. The
>> 5.x javax broker and jakarta client simply cant be used in the same
>> classloader.
>> 
>> 5.x also uses Spring for various bits and a jakarta conversion means
>> using Spring 6, which requires Java 17 as you noted (related aside: 17
>> wont be the current LTS as of next week, with Java 21
>> releasing...which has effectively been finalised for a month now since
>> there was no RC2).
>> 
>> So essentially it is not as simple to have 'javax modules' and
>> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
>> codebase back in February 2021 when that was originally done. That
>> made a lot of sense at the time since noone was really using them back
>> then. Going forward, I do think having 2 versions is actually
>> preferable, and thats what I choose to do elsewhere, and what I'd say
>> most (but, not all) projects are doing at this later point. It does
>> mean backporting things if supporting both, but also means a simpler
>> build and a nicer testing situation etc, and slightly less user change
>> (just updating the version, not knowing new -jakarta dep exists and
>> also updating version).
>> 
>> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org> wrote:
>>> 
>>> I don't have a deep familiarity with the internals here so some of the
>>> fundamentals behind the changes aren't clear to me.
>>> 
>>> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
>>> tightly is "Classic" coupled with Spring?
>>> 
>>> Is the coupling with Spring also why the code-base is being moved
>>> whole-sale to Jakarta? It's been a little while now, but when Artemis
>>> implemented Jakarta support back in early 2021 I don't recall any
>>> disruption for current users and no major version change was needed. Both
>>> Java EE and Jakarta EE implementations are based on the same code-base. Is
>>> something like that not possible here? It would simplify maintenance a lot
>>> since fixes/features wouldn't have to be back-ported.
>>> 
>>> 
>>> Justin
>>> 
>>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
>>> christopher.l.shannon@gmail.com> wrote:
>>> 
>>>> First, I realize that this thread is likely to cause a fight based on past
>>>> history and probably not go anywhere, but with the work being done
>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
>>>> ActiveMQ 6.0 discussion.
>>>> 
>>>> With all the breaking changes currently targeted for version 5.19.x, such
>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
>>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
>>>> to have this next AMQ version as version 5.19.0 as it's completely
>>>> incompatible with the previous version 5.18.x. Users are likely going to be
>>>> in for a rude awakening when trying to upgrade and will be quite confused
>>>> as to why so much is different.
>>>> 
>>>> The Jakarta changes should really be a major version upgrade so that it's
>>>> much more clear to users that it's very different from the previous
>>>> version. Another major benefit of going with version 6.0 is that it frees
>>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
>>>> will likely need to support the older javax releases for quite a while.
>>>> 
>>>> Also, from my point of view it seems pretty clear that the original goal
>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
>>>> its own branding and versioning for several years now and will likely
>>>> continue that way and not change so I don't really see that as a reason to
>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>>>> 
>>>> Anyways, I figure there won't be much agreement here but thought I should
>>>> at least throw it out there before we go and release 5.19.x with such major
>>>> breaking changes.
>>>> 

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
changes to jakarta.jms.

So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
If users want to still use javax.jms then they will use ActiveMQ 5.x,
if they want to use jakarta.jms, they will use ActiveMQ 6.x.

It's clear like this imho.

Regards
JB

On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <ro...@gmail.com> wrote:
>
> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> broker side and also uses the same classes as the client for various
> stuff, so it has to be fully converted so you can use broker + client
> in the same application/test without resorting to containers etc. The
> 5.x javax broker and jakarta client simply cant be used in the same
> classloader.
>
> 5.x also uses Spring for various bits and a jakarta conversion means
> using Spring 6, which requires Java 17 as you noted (related aside: 17
> wont be the current LTS as of next week, with Java 21
> releasing...which has effectively been finalised for a month now since
> there was no RC2).
>
> So essentially it is not as simple to have 'javax modules' and
> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> codebase back in February 2021 when that was originally done. That
> made a lot of sense at the time since noone was really using them back
> then. Going forward, I do think having 2 versions is actually
> preferable, and thats what I choose to do elsewhere, and what I'd say
> most (but, not all) projects are doing at this later point. It does
> mean backporting things if supporting both, but also means a simpler
> build and a nicer testing situation etc, and slightly less user change
> (just updating the version, not knowing new -jakarta dep exists and
> also updating version).
>
> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org> wrote:
> >
> > I don't have a deep familiarity with the internals here so some of the
> > fundamentals behind the changes aren't clear to me.
> >
> > Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> > tightly is "Classic" coupled with Spring?
> >
> > Is the coupling with Spring also why the code-base is being moved
> > whole-sale to Jakarta? It's been a little while now, but when Artemis
> > implemented Jakarta support back in early 2021 I don't recall any
> > disruption for current users and no major version change was needed. Both
> > Java EE and Jakarta EE implementations are based on the same code-base. Is
> > something like that not possible here? It would simplify maintenance a lot
> > since fixes/features wouldn't have to be back-ported.
> >
> >
> > Justin
> >
> > On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > First, I realize that this thread is likely to cause a fight based on past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x, such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going to be
> > > in for a rude awakening when trying to upgrade and will be quite confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it frees
> > > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a reason to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I should
> > > at least throw it out there before we go and release 5.19.x with such major
> > > breaking changes.
> > >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
broker side and also uses the same classes as the client for various
stuff, so it has to be fully converted so you can use broker + client
in the same application/test without resorting to containers etc. The
5.x javax broker and jakarta client simply cant be used in the same
classloader.

5.x also uses Spring for various bits and a jakarta conversion means
using Spring 6, which requires Java 17 as you noted (related aside: 17
wont be the current LTS as of next week, with Java 21
releasing...which has effectively been finalised for a month now since
there was no RC2).

So essentially it is not as simple to have 'javax modules' and
'jakarta modules' in the same tree for 5.x like it was for the Artemis
codebase back in February 2021 when that was originally done. That
made a lot of sense at the time since noone was really using them back
then. Going forward, I do think having 2 versions is actually
preferable, and thats what I choose to do elsewhere, and what I'd say
most (but, not all) projects are doing at this later point. It does
mean backporting things if supporting both, but also means a simpler
build and a nicer testing situation etc, and slightly less user change
(just updating the version, not knowing new -jakarta dep exists and
also updating version).

On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jb...@apache.org> wrote:
>
> I don't have a deep familiarity with the internals here so some of the
> fundamentals behind the changes aren't clear to me.
>
> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> tightly is "Classic" coupled with Spring?
>
> Is the coupling with Spring also why the code-base is being moved
> whole-sale to Jakarta? It's been a little while now, but when Artemis
> implemented Jakarta support back in early 2021 I don't recall any
> disruption for current users and no major version change was needed. Both
> Java EE and Jakarta EE implementations are based on the same code-base. Is
> something like that not possible here? It would simplify maintenance a lot
> since fixes/features wouldn't have to be back-ported.
>
>
> Justin
>
> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > First, I realize that this thread is likely to cause a fight based on past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such major
> > breaking changes.
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Justin Bertram <jb...@apache.org>]

I don't have a deep familiarity with the internals here so some of the
fundamentals behind the changes aren't clear to me.

Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
tightly is "Classic" coupled with Spring?

Is the coupling with Spring also why the code-base is being moved
whole-sale to Jakarta? It's been a little while now, but when Artemis
implemented Jakarta support back in early 2021 I don't recall any
disruption for current users and no major version change was needed. Both
Java EE and Jakarta EE implementations are based on the same code-base. Is
something like that not possible here? It would simplify maintenance a lot
since fixes/features wouldn't have to be back-ported.


Justin

On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Timothy Bish <ta...@gmail.com>]

On 9/11/23 17:14, Christopher Shannon wrote:
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.
>
+1

Seems like a good time to move to 6.x

-- 
Tim Bish

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Francois Papon <fr...@openobject.fr>]

+1

On 12/09/2023 16:15, Jeff Genender wrote:
> +1 to what Christopher said... I have rarely heard AMQ 5.x being referred to as classic.  Most of our users just say "ActiveMQ" or "Artemis".
>
> Jeff
>
>
> On 2023/09/12 13:44:15 Christopher Shannon wrote:
>> I don't really see a need for "Classic" and I think it should be dropped.
>> No one uses it and just refers to it as "ActiveMQ 5.x".
>>
>> ActiveMQ Artemis has had its own versioning and brand since the beginning
>> going back many years so I don't think getting rid of "Classic" is an issue
>> or would lead to any confusion since as I said, no one uses it anyways.
>>
>> So I think it makes sense to just go with what JB said for now:
>>
>> - ActiveMQ 5.18.x
>> - ActiveMQ 6.x.x
>> - ActiveMQ 7.x.x
>> - ActiveMQ Artemis 2.x
>> - ActiveMQ Artemis 3.x
>>
>> That would be quite clear as to what each version is.
>>
>> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> That makes lot of sense to me ! We will have:
>>>
>>> - ActiveMQ 5.18.x
>>> - ActiveMQ 6.x.x
>>> - ActiveMQ 7.x.x
>>> - ActiveMQ Artemis 2.x
>>> - ActiveMQ Artemis 3.x
>>>
>>> So, I propose to have two "spaces" on website:
>>> http://activemq.apache.org/activemq
>>> http://activemq.apache.org/artemis
>>>
>>> The index.html will list the two spaces and users will go to one or
>>> another.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
>>> wrote:
>>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
>>>>
>>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
>>>> <fr...@openobject.fr> wrote:
>>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
>>>>>
>>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
>>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x like
>>> below,
>>>>>> and ActiveMQ Artemis.
>>>>>>
>>>>>> Same as last time this was discussed, I dont consider "Classic" part
>>>>>> of the actual name, just a reflective description label, quoted for a
>>>>>> reason.
>>>>>>
>>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
>>>>>>> Why not simply ActiveMQ and Artemis?
>>>>>>>
>>>>>>> This is how people used to name the 2 projects, I never eared
>>> someone
>>>>>>> say "ActiveMQ Classic".
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> François
>>>>>>>
>>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
>>>>>>>> Same thoughts as last time you proposed it really. Adding Leto
>>> would
>>>>>>>> not be an improvement for me, more actually the reverse. I think
>>> it's
>>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
>>>>>>>> confusing. Describing something as 'classic' is a pretty normal /
>>>>>>>> well-known thing, I think a user even noted that on the original
>>>>>>>> thread.
>>>>>>>>
>>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
>>> jb@nanthrax.net> wrote:
>>>>>>>>> Is it a good time to talk about ActiveMQ "Something" instead of
>>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
>>> and
>>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
>>>>>>>>>
>>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
>>> of
>>>>>>>>> Artemis in Greek mythology) to have a clear distinction between
>>> the
>>>>>>>>> two subprojects. Thoughts ? :)
>>>>>>>>>
>>>>>>>>> If it's too "sensible", please ignore :)
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
>>> wrote:
>>>>>>>>>> makes sense, but please keep a clear distinction - activemq
>>> classic 6.0.0
>>>>>>>>>> activemq X may still evolve to combine the best of both.
>>>>>>>>>>
>>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
>>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> First, I realize that this thread is likely to cause a fight
>>> based on past
>>>>>>>>>>> history and probably not go anywhere, but with the work being
>>> done
>>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
>>> the
>>>>>>>>>>> ActiveMQ 6.0 discussion.
>>>>>>>>>>>
>>>>>>>>>>> With all the breaking changes currently targeted for version
>>> 5.19.x, such
>>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major
>>> Spring and Jetty
>>>>>>>>>>> upgrades and now potentially major OSGi changes, it makes zero
>>> sense to me
>>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
>>> completely
>>>>>>>>>>> incompatible with the previous version 5.18.x. Users are likely
>>> going to be
>>>>>>>>>>> in for a rude awakening when trying to upgrade and will be
>>> quite confused
>>>>>>>>>>> as to why so much is different.
>>>>>>>>>>>
>>>>>>>>>>> The Jakarta changes should really be a major version upgrade so
>>> that it's
>>>>>>>>>>> much more clear to users that it's very different from the
>>> previous
>>>>>>>>>>> version. Another major benefit of going with version 6.0 is
>>> that it frees
>>>>>>>>>>> up the previous javax releases to continue on with 5.19 or 5.20
>>> because we
>>>>>>>>>>> will likely need to support the older javax releases for quite
>>> a while.
>>>>>>>>>>> Also, from my point of view it seems pretty clear that the
>>> original goal
>>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
>>> Artemis has had
>>>>>>>>>>> its own branding and versioning for several years now and will
>>> likely
>>>>>>>>>>> continue that way and not change so I don't really see that as
>>> a reason to
>>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>>>>>>>>>>>
>>>>>>>>>>> Anyways, I figure there won't be much agreement here but
>>> thought I should
>>>>>>>>>>> at least throw it out there before we go and release 5.19.x
>>> with such major
>>>>>>>>>>> breaking changes.
>>>>>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> François
>>>>>>>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

yep, no need for a vote (or even really lazy consensus I'd say) given
the discussion thus far

On Thu, 14 Sept 2023 at 15:09, Christopher Shannon
<ch...@gmail.com> wrote:
>
> Yeah I think lazy consensus is fine here if no major objections come up and
> we can make the change.
>
> On Thu, Sep 14, 2023 at 8:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > I agree about naming. Let's use "Classic" on the index.html page, but
> > not necessary on the "component"/subpage (here we can use ActiveMQ as
> > shortcut).
> >
> > About the version, it seems we are heading to a consensus. Let's wait
> > an additional 24 hours, then, if there are no objections, I will use
> > 6.0.0-SNAPSHOT version on main branch, heading to the 6.0.0 release.
> >
> > Thanks !
> > Regards
> > JB
> >
> > On Thu, Sep 14, 2023 at 12:43 PM Christopher Shannon
> > <ch...@gmail.com> wrote:
> > >
> > > I am ok with whatever makes sense to distinguish the brokers. If people
> > are
> > > starting to use "classic" that is fine. As I previously said I don't
> > think
> > > we necessarily need to make the naming discussion as part of the
> > versioning
> > > discussion.
> > >
> > > I am planning to leave this thread open for another day or so to see if
> > > there is more feedback but if there's no big objections I will start a
> > vote
> > > thread for just bumping the AMQ version to 6.0.0 and we can leave open
> > the
> > > discussion for what to do about the "Classic" name as a separate topic.
> > >
> > > On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
> > > jlmonteiro@tomitribe.com> wrote:
> > >
> > > > Same, when I have to mention both in the same discussion, I tend to add
> > > > "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> > > > But that's basically it.
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef <ar...@apache.org>
> > > > wrote:
> > > >
> > > > > As a general practice, I try to avoid unqualified + qualified names
> > > > > together - it gets confusing.  However, in this case, we have a
> > > > > long-established history.
> > > > >
> > > > > I believe that a formal rename of ActiveMQ would be fairly disruptive
> > > > for a
> > > > > small amount of value.
> > > > >
> > > > > For the record - I have heard, and started using, the term "ActiveMQ
> > > > > Classic" when talking about ActiveMQ + Artemis in the same
> > discussion.
> > > > >
> > > > > Art
> > > > >
> > > > >
> > > > > On Tue, Sep 12, 2023 at 1:52 PM David Blevins <
> > david.blevins@gmail.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jgenender@apache.org
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > > > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > > > > "Artemis".
> > > > > >
> > > > > > Same.  I've never heard anyone contact us and say "Classic".
> > Always
> > > > just
> > > > > > "ActiveMQ" and "Artemis"
> > > > > >
> > > > > >
> > > > > > -David
> > > > > >
> > > > > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > > > > >> I don't really see a need for "Classic" and I think it should be
> > > > > > dropped.
> > > > > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > > > > >>
> > > > > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > > > > beginning
> > > > > > >> going back many years so I don't think getting rid of "Classic"
> > is
> > > > an
> > > > > > issue
> > > > > > >> or would lead to any confusion since as I said, no one uses it
> > > > > anyways.
> > > > > > >>
> > > > > > >> So I think it makes sense to just go with what JB said for now:
> > > > > > >>
> > > > > > >> - ActiveMQ 5.18.x
> > > > > > >> - ActiveMQ 6.x.x
> > > > > > >> - ActiveMQ 7.x.x
> > > > > > >> - ActiveMQ Artemis 2.x
> > > > > > >> - ActiveMQ Artemis 3.x
> > > > > > >>
> > > > > > >> That would be quite clear as to what each version is.
> > > > > > >>
> > > > > > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <
> > > > jb@nanthrax.net
> > > > > >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> That makes lot of sense to me ! We will have:
> > > > > > >>>
> > > > > > >>> - ActiveMQ 5.18.x
> > > > > > >>> - ActiveMQ 6.x.x
> > > > > > >>> - ActiveMQ 7.x.x
> > > > > > >>> - ActiveMQ Artemis 2.x
> > > > > > >>> - ActiveMQ Artemis 3.x
> > > > > > >>>
> > > > > > >>> So, I propose to have two "spaces" on website:
> > > > > > >>> http://activemq.apache.org/activemq
> > > > > > >>> http://activemq.apache.org/artemis
> > > > > > >>>
> > > > > > >>> The index.html will list the two spaces and users will go to
> > one or
> > > > > > >>> another.
> > > > > > >>>
> > > > > > >>> Thoughts ?
> > > > > > >>>
> > > > > > >>> Regards
> > > > > > >>> JB
> > > > > > >>>
> > > > > > >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> > > > > > robbie.gemmell@gmail.com>
> > > > > > >>> wrote:
> > > > > > >>>>
> > > > > > >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > > > > > >>>>
> > > > > > >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > > > > >>>> <fr...@openobject.fr> wrote:
> > > > > > >>>>>
> > > > > > >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > > > > >>>>>
> > > > > > >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > > >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x
> > like
> > > > > > >>> below,
> > > > > > >>>>>> and ActiveMQ Artemis.
> > > > > > >>>>>>
> > > > > > >>>>>> Same as last time this was discussed, I dont consider
> > "Classic"
> > > > > part
> > > > > > >>>>>> of the actual name, just a reflective description label,
> > quoted
> > > > > for
> > > > > > a
> > > > > > >>>>>> reason.
> > > > > > >>>>>>
> > > > > > >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org>
> > > > wrote:
> > > > > > >>>>>>> Why not simply ActiveMQ and Artemis?
> > > > > > >>>>>>>
> > > > > > >>>>>>> This is how people used to name the 2 projects, I never
> > eared
> > > > > > >>> someone
> > > > > > >>>>>>> say "ActiveMQ Classic".
> > > > > > >>>>>>>
> > > > > > >>>>>>> regards,
> > > > > > >>>>>>>
> > > > > > >>>>>>> François
> > > > > > >>>>>>>
> > > > > > >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > > > >>>>>>>> Same thoughts as last time you proposed it really. Adding
> > Leto
> > > > > > >>> would
> > > > > > >>>>>>>> not be an improvement for me, more actually the reverse. I
> > > > think
> > > > > > >>> it's
> > > > > > >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be
> > more
> > > > > > >>>>>>>> confusing. Describing something as 'classic' is a pretty
> > > > normal
> > > > > /
> > > > > > >>>>>>>> well-known thing, I think a user even noted that on the
> > > > original
> > > > > > >>>>>>>> thread.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > > > > > >>> jb@nanthrax.net> wrote:
> > > > > > >>>>>>>>> Is it a good time to talk about ActiveMQ "Something"
> > instead
> > > > of
> > > > > > >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds
> > weird to
> > > > > me)
> > > > > > >>> and
> > > > > > >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is
> > the
> > > > > mother
> > > > > > >>> of
> > > > > > >>>>>>>>> Artemis in Greek mythology) to have a clear distinction
> > > > between
> > > > > > >>> the
> > > > > > >>>>>>>>> two subprojects. Thoughts ? :)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> If it's too "sensible", please ignore :)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Regards
> > > > > > >>>>>>>>> JB
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <
> > > > gtully@apache.org
> > > > > >
> > > > > > >>> wrote:
> > > > > > >>>>>>>>>> makes sense, but please keep a clear distinction -
> > activemq
> > > > > > >>> classic 6.0.0
> > > > > > >>>>>>>>>> activemq X may still evolve to combine the best of both.
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > > > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> First, I realize that this thread is likely to cause a
> > > > fight
> > > > > > >>> based on past
> > > > > > >>>>>>>>>>> history and probably not go anywhere, but with the work
> > > > being
> > > > > > >>> done
> > > > > > >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least
> > > > bring
> > > > > up
> > > > > > >>> the
> > > > > > >>>>>>>>>>> ActiveMQ 6.0 discussion.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> With all the breaking changes currently targeted for
> > > > version
> > > > > > >>> 5.19.x, such
> > > > > > >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17,
> > major
> > > > > > >>> Spring and Jetty
> > > > > > >>>>>>>>>>> upgrades and now potentially major OSGi changes, it
> > makes
> > > > > zero
> > > > > > >>> sense to me
> > > > > > >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> > > > > > >>> completely
> > > > > > >>>>>>>>>>> incompatible with the previous version 5.18.x. Users
> > are
> > > > > likely
> > > > > > >>> going to be
> > > > > > >>>>>>>>>>> in for a rude awakening when trying to upgrade and
> > will be
> > > > > > >>> quite confused
> > > > > > >>>>>>>>>>> as to why so much is different.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> The Jakarta changes should really be a major version
> > > > upgrade
> > > > > so
> > > > > > >>> that it's
> > > > > > >>>>>>>>>>> much more clear to users that it's very different from
> > the
> > > > > > >>> previous
> > > > > > >>>>>>>>>>> version. Another major benefit of going with version
> > 6.0 is
> > > > > > >>> that it frees
> > > > > > >>>>>>>>>>> up the previous javax releases to continue on with
> > 5.19 or
> > > > > 5.20
> > > > > > >>> because we
> > > > > > >>>>>>>>>>> will likely need to support the older javax releases
> > for
> > > > > quite
> > > > > > >>> a while.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> Also, from my point of view it seems pretty clear that
> > the
> > > > > > >>> original goal
> > > > > > >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to
> > happen.
> > > > > > >>> Artemis has had
> > > > > > >>>>>>>>>>> its own branding and versioning for several years now
> > and
> > > > > will
> > > > > > >>> likely
> > > > > > >>>>>>>>>>> continue that way and not change so I don't really see
> > that
> > > > > as
> > > > > > >>> a reason to
> > > > > > >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking
> > > > changes.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> Anyways, I figure there won't be much agreement here
> > but
> > > > > > >>> thought I should
> > > > > > >>>>>>>>>>> at least throw it out there before we go and release
> > 5.19.x
> > > > > > >>> with such major
> > > > > > >>>>>>>>>>> breaking changes.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>> --
> > > > > > >>>>>>> --
> > > > > > >>>>>>> François
> > > > > > >>>>>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Christopher Shannon <ch...@gmail.com>]

Yeah I think lazy consensus is fine here if no major objections come up and
we can make the change.

On Thu, Sep 14, 2023 at 8:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> I agree about naming. Let's use "Classic" on the index.html page, but
> not necessary on the "component"/subpage (here we can use ActiveMQ as
> shortcut).
>
> About the version, it seems we are heading to a consensus. Let's wait
> an additional 24 hours, then, if there are no objections, I will use
> 6.0.0-SNAPSHOT version on main branch, heading to the 6.0.0 release.
>
> Thanks !
> Regards
> JB
>
> On Thu, Sep 14, 2023 at 12:43 PM Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > I am ok with whatever makes sense to distinguish the brokers. If people
> are
> > starting to use "classic" that is fine. As I previously said I don't
> think
> > we necessarily need to make the naming discussion as part of the
> versioning
> > discussion.
> >
> > I am planning to leave this thread open for another day or so to see if
> > there is more feedback but if there's no big objections I will start a
> vote
> > thread for just bumping the AMQ version to 6.0.0 and we can leave open
> the
> > discussion for what to do about the "Classic" name as a separate topic.
> >
> > On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> >
> > > Same, when I have to mention both in the same discussion, I tend to add
> > > "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> > > But that's basically it.
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef <ar...@apache.org>
> > > wrote:
> > >
> > > > As a general practice, I try to avoid unqualified + qualified names
> > > > together - it gets confusing.  However, in this case, we have a
> > > > long-established history.
> > > >
> > > > I believe that a formal rename of ActiveMQ would be fairly disruptive
> > > for a
> > > > small amount of value.
> > > >
> > > > For the record - I have heard, and started using, the term "ActiveMQ
> > > > Classic" when talking about ActiveMQ + Artemis in the same
> discussion.
> > > >
> > > > Art
> > > >
> > > >
> > > > On Tue, Sep 12, 2023 at 1:52 PM David Blevins <
> david.blevins@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jgenender@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > > > "Artemis".
> > > > >
> > > > > Same.  I've never heard anyone contact us and say "Classic".
> Always
> > > just
> > > > > "ActiveMQ" and "Artemis"
> > > > >
> > > > >
> > > > > -David
> > > > >
> > > > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > > > >> I don't really see a need for "Classic" and I think it should be
> > > > > dropped.
> > > > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > > > >>
> > > > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > > > beginning
> > > > > >> going back many years so I don't think getting rid of "Classic"
> is
> > > an
> > > > > issue
> > > > > >> or would lead to any confusion since as I said, no one uses it
> > > > anyways.
> > > > > >>
> > > > > >> So I think it makes sense to just go with what JB said for now:
> > > > > >>
> > > > > >> - ActiveMQ 5.18.x
> > > > > >> - ActiveMQ 6.x.x
> > > > > >> - ActiveMQ 7.x.x
> > > > > >> - ActiveMQ Artemis 2.x
> > > > > >> - ActiveMQ Artemis 3.x
> > > > > >>
> > > > > >> That would be quite clear as to what each version is.
> > > > > >>
> > > > > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <
> > > jb@nanthrax.net
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> That makes lot of sense to me ! We will have:
> > > > > >>>
> > > > > >>> - ActiveMQ 5.18.x
> > > > > >>> - ActiveMQ 6.x.x
> > > > > >>> - ActiveMQ 7.x.x
> > > > > >>> - ActiveMQ Artemis 2.x
> > > > > >>> - ActiveMQ Artemis 3.x
> > > > > >>>
> > > > > >>> So, I propose to have two "spaces" on website:
> > > > > >>> http://activemq.apache.org/activemq
> > > > > >>> http://activemq.apache.org/artemis
> > > > > >>>
> > > > > >>> The index.html will list the two spaces and users will go to
> one or
> > > > > >>> another.
> > > > > >>>
> > > > > >>> Thoughts ?
> > > > > >>>
> > > > > >>> Regards
> > > > > >>> JB
> > > > > >>>
> > > > > >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> > > > > robbie.gemmell@gmail.com>
> > > > > >>> wrote:
> > > > > >>>>
> > > > > >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > > > > >>>>
> > > > > >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > > > >>>> <fr...@openobject.fr> wrote:
> > > > > >>>>>
> > > > > >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > > > >>>>>
> > > > > >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x
> like
> > > > > >>> below,
> > > > > >>>>>> and ActiveMQ Artemis.
> > > > > >>>>>>
> > > > > >>>>>> Same as last time this was discussed, I dont consider
> "Classic"
> > > > part
> > > > > >>>>>> of the actual name, just a reflective description label,
> quoted
> > > > for
> > > > > a
> > > > > >>>>>> reason.
> > > > > >>>>>>
> > > > > >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org>
> > > wrote:
> > > > > >>>>>>> Why not simply ActiveMQ and Artemis?
> > > > > >>>>>>>
> > > > > >>>>>>> This is how people used to name the 2 projects, I never
> eared
> > > > > >>> someone
> > > > > >>>>>>> say "ActiveMQ Classic".
> > > > > >>>>>>>
> > > > > >>>>>>> regards,
> > > > > >>>>>>>
> > > > > >>>>>>> François
> > > > > >>>>>>>
> > > > > >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > > >>>>>>>> Same thoughts as last time you proposed it really. Adding
> Leto
> > > > > >>> would
> > > > > >>>>>>>> not be an improvement for me, more actually the reverse. I
> > > think
> > > > > >>> it's
> > > > > >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be
> more
> > > > > >>>>>>>> confusing. Describing something as 'classic' is a pretty
> > > normal
> > > > /
> > > > > >>>>>>>> well-known thing, I think a user even noted that on the
> > > original
> > > > > >>>>>>>> thread.
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > > > > >>> jb@nanthrax.net> wrote:
> > > > > >>>>>>>>> Is it a good time to talk about ActiveMQ "Something"
> instead
> > > of
> > > > > >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds
> weird to
> > > > me)
> > > > > >>> and
> > > > > >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is
> the
> > > > mother
> > > > > >>> of
> > > > > >>>>>>>>> Artemis in Greek mythology) to have a clear distinction
> > > between
> > > > > >>> the
> > > > > >>>>>>>>> two subprojects. Thoughts ? :)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> If it's too "sensible", please ignore :)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Regards
> > > > > >>>>>>>>> JB
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <
> > > gtully@apache.org
> > > > >
> > > > > >>> wrote:
> > > > > >>>>>>>>>> makes sense, but please keep a clear distinction -
> activemq
> > > > > >>> classic 6.0.0
> > > > > >>>>>>>>>> activemq X may still evolve to combine the best of both.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> First, I realize that this thread is likely to cause a
> > > fight
> > > > > >>> based on past
> > > > > >>>>>>>>>>> history and probably not go anywhere, but with the work
> > > being
> > > > > >>> done
> > > > > >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least
> > > bring
> > > > up
> > > > > >>> the
> > > > > >>>>>>>>>>> ActiveMQ 6.0 discussion.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> With all the breaking changes currently targeted for
> > > version
> > > > > >>> 5.19.x, such
> > > > > >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17,
> major
> > > > > >>> Spring and Jetty
> > > > > >>>>>>>>>>> upgrades and now potentially major OSGi changes, it
> makes
> > > > zero
> > > > > >>> sense to me
> > > > > >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> > > > > >>> completely
> > > > > >>>>>>>>>>> incompatible with the previous version 5.18.x. Users
> are
> > > > likely
> > > > > >>> going to be
> > > > > >>>>>>>>>>> in for a rude awakening when trying to upgrade and
> will be
> > > > > >>> quite confused
> > > > > >>>>>>>>>>> as to why so much is different.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> The Jakarta changes should really be a major version
> > > upgrade
> > > > so
> > > > > >>> that it's
> > > > > >>>>>>>>>>> much more clear to users that it's very different from
> the
> > > > > >>> previous
> > > > > >>>>>>>>>>> version. Another major benefit of going with version
> 6.0 is
> > > > > >>> that it frees
> > > > > >>>>>>>>>>> up the previous javax releases to continue on with
> 5.19 or
> > > > 5.20
> > > > > >>> because we
> > > > > >>>>>>>>>>> will likely need to support the older javax releases
> for
> > > > quite
> > > > > >>> a while.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Also, from my point of view it seems pretty clear that
> the
> > > > > >>> original goal
> > > > > >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to
> happen.
> > > > > >>> Artemis has had
> > > > > >>>>>>>>>>> its own branding and versioning for several years now
> and
> > > > will
> > > > > >>> likely
> > > > > >>>>>>>>>>> continue that way and not change so I don't really see
> that
> > > > as
> > > > > >>> a reason to
> > > > > >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking
> > > changes.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Anyways, I figure there won't be much agreement here
> but
> > > > > >>> thought I should
> > > > > >>>>>>>>>>> at least throw it out there before we go and release
> 5.19.x
> > > > > >>> with such major
> > > > > >>>>>>>>>>> breaking changes.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>> --
> > > > > >>>>>>> --
> > > > > >>>>>>> François
> > > > > >>>>>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Arthur Naseef <ar...@apache.org>]

If we do update the website for naming - I recommend we just call refer to
"ActiveMQ Classic" as an alias.  For example (totally made up), "We have 2
brokers, ActiveMQ (aka ActiveMQ Classic) and ActiveMQ Artemis".

Art


On Thu, Sep 14, 2023 at 5:19 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> I agree about naming. Let's use "Classic" on the index.html page, but
> not necessary on the "component"/subpage (here we can use ActiveMQ as
> shortcut).
>
> About the version, it seems we are heading to a consensus. Let's wait
> an additional 24 hours, then, if there are no objections, I will use
> 6.0.0-SNAPSHOT version on main branch, heading to the 6.0.0 release.
>
> Thanks !
> Regards
> JB
>
> On Thu, Sep 14, 2023 at 12:43 PM Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > I am ok with whatever makes sense to distinguish the brokers. If people
> are
> > starting to use "classic" that is fine. As I previously said I don't
> think
> > we necessarily need to make the naming discussion as part of the
> versioning
> > discussion.
> >
> > I am planning to leave this thread open for another day or so to see if
> > there is more feedback but if there's no big objections I will start a
> vote
> > thread for just bumping the AMQ version to 6.0.0 and we can leave open
> the
> > discussion for what to do about the "Classic" name as a separate topic.
> >
> > On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> >
> > > Same, when I have to mention both in the same discussion, I tend to add
> > > "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> > > But that's basically it.
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef <ar...@apache.org>
> > > wrote:
> > >
> > > > As a general practice, I try to avoid unqualified + qualified names
> > > > together - it gets confusing.  However, in this case, we have a
> > > > long-established history.
> > > >
> > > > I believe that a formal rename of ActiveMQ would be fairly disruptive
> > > for a
> > > > small amount of value.
> > > >
> > > > For the record - I have heard, and started using, the term "ActiveMQ
> > > > Classic" when talking about ActiveMQ + Artemis in the same
> discussion.
> > > >
> > > > Art
> > > >
> > > >
> > > > On Tue, Sep 12, 2023 at 1:52 PM David Blevins <
> david.blevins@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jgenender@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > > > "Artemis".
> > > > >
> > > > > Same.  I've never heard anyone contact us and say "Classic".
> Always
> > > just
> > > > > "ActiveMQ" and "Artemis"
> > > > >
> > > > >
> > > > > -David
> > > > >
> > > > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > > > >> I don't really see a need for "Classic" and I think it should be
> > > > > dropped.
> > > > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > > > >>
> > > > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > > > beginning
> > > > > >> going back many years so I don't think getting rid of "Classic"
> is
> > > an
> > > > > issue
> > > > > >> or would lead to any confusion since as I said, no one uses it
> > > > anyways.
> > > > > >>
> > > > > >> So I think it makes sense to just go with what JB said for now:
> > > > > >>
> > > > > >> - ActiveMQ 5.18.x
> > > > > >> - ActiveMQ 6.x.x
> > > > > >> - ActiveMQ 7.x.x
> > > > > >> - ActiveMQ Artemis 2.x
> > > > > >> - ActiveMQ Artemis 3.x
> > > > > >>
> > > > > >> That would be quite clear as to what each version is.
> > > > > >>
> > > > > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <
> > > jb@nanthrax.net
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> That makes lot of sense to me ! We will have:
> > > > > >>>
> > > > > >>> - ActiveMQ 5.18.x
> > > > > >>> - ActiveMQ 6.x.x
> > > > > >>> - ActiveMQ 7.x.x
> > > > > >>> - ActiveMQ Artemis 2.x
> > > > > >>> - ActiveMQ Artemis 3.x
> > > > > >>>
> > > > > >>> So, I propose to have two "spaces" on website:
> > > > > >>> http://activemq.apache.org/activemq
> > > > > >>> http://activemq.apache.org/artemis
> > > > > >>>
> > > > > >>> The index.html will list the two spaces and users will go to
> one or
> > > > > >>> another.
> > > > > >>>
> > > > > >>> Thoughts ?
> > > > > >>>
> > > > > >>> Regards
> > > > > >>> JB
> > > > > >>>
> > > > > >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> > > > > robbie.gemmell@gmail.com>
> > > > > >>> wrote:
> > > > > >>>>
> > > > > >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > > > > >>>>
> > > > > >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > > > >>>> <fr...@openobject.fr> wrote:
> > > > > >>>>>
> > > > > >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > > > >>>>>
> > > > > >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x
> like
> > > > > >>> below,
> > > > > >>>>>> and ActiveMQ Artemis.
> > > > > >>>>>>
> > > > > >>>>>> Same as last time this was discussed, I dont consider
> "Classic"
> > > > part
> > > > > >>>>>> of the actual name, just a reflective description label,
> quoted
> > > > for
> > > > > a
> > > > > >>>>>> reason.
> > > > > >>>>>>
> > > > > >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org>
> > > wrote:
> > > > > >>>>>>> Why not simply ActiveMQ and Artemis?
> > > > > >>>>>>>
> > > > > >>>>>>> This is how people used to name the 2 projects, I never
> eared
> > > > > >>> someone
> > > > > >>>>>>> say "ActiveMQ Classic".
> > > > > >>>>>>>
> > > > > >>>>>>> regards,
> > > > > >>>>>>>
> > > > > >>>>>>> François
> > > > > >>>>>>>
> > > > > >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > > >>>>>>>> Same thoughts as last time you proposed it really. Adding
> Leto
> > > > > >>> would
> > > > > >>>>>>>> not be an improvement for me, more actually the reverse. I
> > > think
> > > > > >>> it's
> > > > > >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be
> more
> > > > > >>>>>>>> confusing. Describing something as 'classic' is a pretty
> > > normal
> > > > /
> > > > > >>>>>>>> well-known thing, I think a user even noted that on the
> > > original
> > > > > >>>>>>>> thread.
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > > > > >>> jb@nanthrax.net> wrote:
> > > > > >>>>>>>>> Is it a good time to talk about ActiveMQ "Something"
> instead
> > > of
> > > > > >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds
> weird to
> > > > me)
> > > > > >>> and
> > > > > >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is
> the
> > > > mother
> > > > > >>> of
> > > > > >>>>>>>>> Artemis in Greek mythology) to have a clear distinction
> > > between
> > > > > >>> the
> > > > > >>>>>>>>> two subprojects. Thoughts ? :)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> If it's too "sensible", please ignore :)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Regards
> > > > > >>>>>>>>> JB
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <
> > > gtully@apache.org
> > > > >
> > > > > >>> wrote:
> > > > > >>>>>>>>>> makes sense, but please keep a clear distinction -
> activemq
> > > > > >>> classic 6.0.0
> > > > > >>>>>>>>>> activemq X may still evolve to combine the best of both.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> First, I realize that this thread is likely to cause a
> > > fight
> > > > > >>> based on past
> > > > > >>>>>>>>>>> history and probably not go anywhere, but with the work
> > > being
> > > > > >>> done
> > > > > >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least
> > > bring
> > > > up
> > > > > >>> the
> > > > > >>>>>>>>>>> ActiveMQ 6.0 discussion.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> With all the breaking changes currently targeted for
> > > version
> > > > > >>> 5.19.x, such
> > > > > >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17,
> major
> > > > > >>> Spring and Jetty
> > > > > >>>>>>>>>>> upgrades and now potentially major OSGi changes, it
> makes
> > > > zero
> > > > > >>> sense to me
> > > > > >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> > > > > >>> completely
> > > > > >>>>>>>>>>> incompatible with the previous version 5.18.x. Users
> are
> > > > likely
> > > > > >>> going to be
> > > > > >>>>>>>>>>> in for a rude awakening when trying to upgrade and
> will be
> > > > > >>> quite confused
> > > > > >>>>>>>>>>> as to why so much is different.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> The Jakarta changes should really be a major version
> > > upgrade
> > > > so
> > > > > >>> that it's
> > > > > >>>>>>>>>>> much more clear to users that it's very different from
> the
> > > > > >>> previous
> > > > > >>>>>>>>>>> version. Another major benefit of going with version
> 6.0 is
> > > > > >>> that it frees
> > > > > >>>>>>>>>>> up the previous javax releases to continue on with
> 5.19 or
> > > > 5.20
> > > > > >>> because we
> > > > > >>>>>>>>>>> will likely need to support the older javax releases
> for
> > > > quite
> > > > > >>> a while.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Also, from my point of view it seems pretty clear that
> the
> > > > > >>> original goal
> > > > > >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to
> happen.
> > > > > >>> Artemis has had
> > > > > >>>>>>>>>>> its own branding and versioning for several years now
> and
> > > > will
> > > > > >>> likely
> > > > > >>>>>>>>>>> continue that way and not change so I don't really see
> that
> > > > as
> > > > > >>> a reason to
> > > > > >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking
> > > changes.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Anyways, I figure there won't be much agreement here
> but
> > > > > >>> thought I should
> > > > > >>>>>>>>>>> at least throw it out there before we go and release
> 5.19.x
> > > > > >>> with such major
> > > > > >>>>>>>>>>> breaking changes.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>> --
> > > > > >>>>>>> --
> > > > > >>>>>>> François
> > > > > >>>>>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

I agree about naming. Let's use "Classic" on the index.html page, but
not necessary on the "component"/subpage (here we can use ActiveMQ as
shortcut).

About the version, it seems we are heading to a consensus. Let's wait
an additional 24 hours, then, if there are no objections, I will use
6.0.0-SNAPSHOT version on main branch, heading to the 6.0.0 release.

Thanks !
Regards
JB

On Thu, Sep 14, 2023 at 12:43 PM Christopher Shannon
<ch...@gmail.com> wrote:
>
> I am ok with whatever makes sense to distinguish the brokers. If people are
> starting to use "classic" that is fine. As I previously said I don't think
> we necessarily need to make the naming discussion as part of the versioning
> discussion.
>
> I am planning to leave this thread open for another day or so to see if
> there is more feedback but if there's no big objections I will start a vote
> thread for just bumping the AMQ version to 6.0.0 and we can leave open the
> discussion for what to do about the "Classic" name as a separate topic.
>
> On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
> > Same, when I have to mention both in the same discussion, I tend to add
> > "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> > But that's basically it.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef <ar...@apache.org>
> > wrote:
> >
> > > As a general practice, I try to avoid unqualified + qualified names
> > > together - it gets confusing.  However, in this case, we have a
> > > long-established history.
> > >
> > > I believe that a formal rename of ActiveMQ would be fairly disruptive
> > for a
> > > small amount of value.
> > >
> > > For the record - I have heard, and started using, the term "ActiveMQ
> > > Classic" when talking about ActiveMQ + Artemis in the same discussion.
> > >
> > > Art
> > >
> > >
> > > On Tue, Sep 12, 2023 at 1:52 PM David Blevins <da...@gmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jg...@apache.org>
> > > wrote:
> > > > >
> > > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > > "Artemis".
> > > >
> > > > Same.  I've never heard anyone contact us and say "Classic".  Always
> > just
> > > > "ActiveMQ" and "Artemis"
> > > >
> > > >
> > > > -David
> > > >
> > > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > > >> I don't really see a need for "Classic" and I think it should be
> > > > dropped.
> > > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > > >>
> > > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > > beginning
> > > > >> going back many years so I don't think getting rid of "Classic" is
> > an
> > > > issue
> > > > >> or would lead to any confusion since as I said, no one uses it
> > > anyways.
> > > > >>
> > > > >> So I think it makes sense to just go with what JB said for now:
> > > > >>
> > > > >> - ActiveMQ 5.18.x
> > > > >> - ActiveMQ 6.x.x
> > > > >> - ActiveMQ 7.x.x
> > > > >> - ActiveMQ Artemis 2.x
> > > > >> - ActiveMQ Artemis 3.x
> > > > >>
> > > > >> That would be quite clear as to what each version is.
> > > > >>
> > > > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <
> > jb@nanthrax.net
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> That makes lot of sense to me ! We will have:
> > > > >>>
> > > > >>> - ActiveMQ 5.18.x
> > > > >>> - ActiveMQ 6.x.x
> > > > >>> - ActiveMQ 7.x.x
> > > > >>> - ActiveMQ Artemis 2.x
> > > > >>> - ActiveMQ Artemis 3.x
> > > > >>>
> > > > >>> So, I propose to have two "spaces" on website:
> > > > >>> http://activemq.apache.org/activemq
> > > > >>> http://activemq.apache.org/artemis
> > > > >>>
> > > > >>> The index.html will list the two spaces and users will go to one or
> > > > >>> another.
> > > > >>>
> > > > >>> Thoughts ?
> > > > >>>
> > > > >>> Regards
> > > > >>> JB
> > > > >>>
> > > > >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> > > > robbie.gemmell@gmail.com>
> > > > >>> wrote:
> > > > >>>>
> > > > >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > > > >>>>
> > > > >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > > >>>> <fr...@openobject.fr> wrote:
> > > > >>>>>
> > > > >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > > >>>>>
> > > > >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x like
> > > > >>> below,
> > > > >>>>>> and ActiveMQ Artemis.
> > > > >>>>>>
> > > > >>>>>> Same as last time this was discussed, I dont consider "Classic"
> > > part
> > > > >>>>>> of the actual name, just a reflective description label, quoted
> > > for
> > > > a
> > > > >>>>>> reason.
> > > > >>>>>>
> > > > >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org>
> > wrote:
> > > > >>>>>>> Why not simply ActiveMQ and Artemis?
> > > > >>>>>>>
> > > > >>>>>>> This is how people used to name the 2 projects, I never eared
> > > > >>> someone
> > > > >>>>>>> say "ActiveMQ Classic".
> > > > >>>>>>>
> > > > >>>>>>> regards,
> > > > >>>>>>>
> > > > >>>>>>> François
> > > > >>>>>>>
> > > > >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > >>>>>>>> Same thoughts as last time you proposed it really. Adding Leto
> > > > >>> would
> > > > >>>>>>>> not be an improvement for me, more actually the reverse. I
> > think
> > > > >>> it's
> > > > >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > > >>>>>>>> confusing. Describing something as 'classic' is a pretty
> > normal
> > > /
> > > > >>>>>>>> well-known thing, I think a user even noted that on the
> > original
> > > > >>>>>>>> thread.
> > > > >>>>>>>>
> > > > >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > > > >>> jb@nanthrax.net> wrote:
> > > > >>>>>>>>> Is it a good time to talk about ActiveMQ "Something" instead
> > of
> > > > >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to
> > > me)
> > > > >>> and
> > > > >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > >>>>>>>>>
> > > > >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the
> > > mother
> > > > >>> of
> > > > >>>>>>>>> Artemis in Greek mythology) to have a clear distinction
> > between
> > > > >>> the
> > > > >>>>>>>>> two subprojects. Thoughts ? :)
> > > > >>>>>>>>>
> > > > >>>>>>>>> If it's too "sensible", please ignore :)
> > > > >>>>>>>>>
> > > > >>>>>>>>> Regards
> > > > >>>>>>>>> JB
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <
> > gtully@apache.org
> > > >
> > > > >>> wrote:
> > > > >>>>>>>>>> makes sense, but please keep a clear distinction - activemq
> > > > >>> classic 6.0.0
> > > > >>>>>>>>>> activemq X may still evolve to combine the best of both.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> First, I realize that this thread is likely to cause a
> > fight
> > > > >>> based on past
> > > > >>>>>>>>>>> history and probably not go anywhere, but with the work
> > being
> > > > >>> done
> > > > >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least
> > bring
> > > up
> > > > >>> the
> > > > >>>>>>>>>>> ActiveMQ 6.0 discussion.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> With all the breaking changes currently targeted for
> > version
> > > > >>> 5.19.x, such
> > > > >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> > > > >>> Spring and Jetty
> > > > >>>>>>>>>>> upgrades and now potentially major OSGi changes, it makes
> > > zero
> > > > >>> sense to me
> > > > >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> > > > >>> completely
> > > > >>>>>>>>>>> incompatible with the previous version 5.18.x. Users are
> > > likely
> > > > >>> going to be
> > > > >>>>>>>>>>> in for a rude awakening when trying to upgrade and will be
> > > > >>> quite confused
> > > > >>>>>>>>>>> as to why so much is different.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> The Jakarta changes should really be a major version
> > upgrade
> > > so
> > > > >>> that it's
> > > > >>>>>>>>>>> much more clear to users that it's very different from the
> > > > >>> previous
> > > > >>>>>>>>>>> version. Another major benefit of going with version 6.0 is
> > > > >>> that it frees
> > > > >>>>>>>>>>> up the previous javax releases to continue on with 5.19 or
> > > 5.20
> > > > >>> because we
> > > > >>>>>>>>>>> will likely need to support the older javax releases for
> > > quite
> > > > >>> a while.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Also, from my point of view it seems pretty clear that the
> > > > >>> original goal
> > > > >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> > > > >>> Artemis has had
> > > > >>>>>>>>>>> its own branding and versioning for several years now and
> > > will
> > > > >>> likely
> > > > >>>>>>>>>>> continue that way and not change so I don't really see that
> > > as
> > > > >>> a reason to
> > > > >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking
> > changes.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Anyways, I figure there won't be much agreement here but
> > > > >>> thought I should
> > > > >>>>>>>>>>> at least throw it out there before we go and release 5.19.x
> > > > >>> with such major
> > > > >>>>>>>>>>> breaking changes.
> > > > >>>>>>>>>>>
> > > > >>>>>>> --
> > > > >>>>>>> --
> > > > >>>>>>> François
> > > > >>>>>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Christopher Shannon <ch...@gmail.com>]

I am ok with whatever makes sense to distinguish the brokers. If people are
starting to use "classic" that is fine. As I previously said I don't think
we necessarily need to make the naming discussion as part of the versioning
discussion.

I am planning to leave this thread open for another day or so to see if
there is more feedback but if there's no big objections I will start a vote
thread for just bumping the AMQ version to 6.0.0 and we can leave open the
discussion for what to do about the "Classic" name as a separate topic.

On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:

> Same, when I have to mention both in the same discussion, I tend to add
> "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> But that's basically it.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef <ar...@apache.org>
> wrote:
>
> > As a general practice, I try to avoid unqualified + qualified names
> > together - it gets confusing.  However, in this case, we have a
> > long-established history.
> >
> > I believe that a formal rename of ActiveMQ would be fairly disruptive
> for a
> > small amount of value.
> >
> > For the record - I have heard, and started using, the term "ActiveMQ
> > Classic" when talking about ActiveMQ + Artemis in the same discussion.
> >
> > Art
> >
> >
> > On Tue, Sep 12, 2023 at 1:52 PM David Blevins <da...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jg...@apache.org>
> > wrote:
> > > >
> > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > "Artemis".
> > >
> > > Same.  I've never heard anyone contact us and say "Classic".  Always
> just
> > > "ActiveMQ" and "Artemis"
> > >
> > >
> > > -David
> > >
> > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > >> I don't really see a need for "Classic" and I think it should be
> > > dropped.
> > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > >>
> > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > beginning
> > > >> going back many years so I don't think getting rid of "Classic" is
> an
> > > issue
> > > >> or would lead to any confusion since as I said, no one uses it
> > anyways.
> > > >>
> > > >> So I think it makes sense to just go with what JB said for now:
> > > >>
> > > >> - ActiveMQ 5.18.x
> > > >> - ActiveMQ 6.x.x
> > > >> - ActiveMQ 7.x.x
> > > >> - ActiveMQ Artemis 2.x
> > > >> - ActiveMQ Artemis 3.x
> > > >>
> > > >> That would be quite clear as to what each version is.
> > > >>
> > > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <
> jb@nanthrax.net
> > >
> > > >> wrote:
> > > >>
> > > >>> That makes lot of sense to me ! We will have:
> > > >>>
> > > >>> - ActiveMQ 5.18.x
> > > >>> - ActiveMQ 6.x.x
> > > >>> - ActiveMQ 7.x.x
> > > >>> - ActiveMQ Artemis 2.x
> > > >>> - ActiveMQ Artemis 3.x
> > > >>>
> > > >>> So, I propose to have two "spaces" on website:
> > > >>> http://activemq.apache.org/activemq
> > > >>> http://activemq.apache.org/artemis
> > > >>>
> > > >>> The index.html will list the two spaces and users will go to one or
> > > >>> another.
> > > >>>
> > > >>> Thoughts ?
> > > >>>
> > > >>> Regards
> > > >>> JB
> > > >>>
> > > >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> > > robbie.gemmell@gmail.com>
> > > >>> wrote:
> > > >>>>
> > > >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > > >>>>
> > > >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > >>>> <fr...@openobject.fr> wrote:
> > > >>>>>
> > > >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > >>>>>
> > > >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x like
> > > >>> below,
> > > >>>>>> and ActiveMQ Artemis.
> > > >>>>>>
> > > >>>>>> Same as last time this was discussed, I dont consider "Classic"
> > part
> > > >>>>>> of the actual name, just a reflective description label, quoted
> > for
> > > a
> > > >>>>>> reason.
> > > >>>>>>
> > > >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org>
> wrote:
> > > >>>>>>> Why not simply ActiveMQ and Artemis?
> > > >>>>>>>
> > > >>>>>>> This is how people used to name the 2 projects, I never eared
> > > >>> someone
> > > >>>>>>> say "ActiveMQ Classic".
> > > >>>>>>>
> > > >>>>>>> regards,
> > > >>>>>>>
> > > >>>>>>> François
> > > >>>>>>>
> > > >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > >>>>>>>> Same thoughts as last time you proposed it really. Adding Leto
> > > >>> would
> > > >>>>>>>> not be an improvement for me, more actually the reverse. I
> think
> > > >>> it's
> > > >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > >>>>>>>> confusing. Describing something as 'classic' is a pretty
> normal
> > /
> > > >>>>>>>> well-known thing, I think a user even noted that on the
> original
> > > >>>>>>>> thread.
> > > >>>>>>>>
> > > >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > > >>> jb@nanthrax.net> wrote:
> > > >>>>>>>>> Is it a good time to talk about ActiveMQ "Something" instead
> of
> > > >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to
> > me)
> > > >>> and
> > > >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> > > >>>>>>>>>
> > > >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the
> > mother
> > > >>> of
> > > >>>>>>>>> Artemis in Greek mythology) to have a clear distinction
> between
> > > >>> the
> > > >>>>>>>>> two subprojects. Thoughts ? :)
> > > >>>>>>>>>
> > > >>>>>>>>> If it's too "sensible", please ignore :)
> > > >>>>>>>>>
> > > >>>>>>>>> Regards
> > > >>>>>>>>> JB
> > > >>>>>>>>>
> > > >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <
> gtully@apache.org
> > >
> > > >>> wrote:
> > > >>>>>>>>>> makes sense, but please keep a clear distinction - activemq
> > > >>> classic 6.0.0
> > > >>>>>>>>>> activemq X may still evolve to combine the best of both.
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> First, I realize that this thread is likely to cause a
> fight
> > > >>> based on past
> > > >>>>>>>>>>> history and probably not go anywhere, but with the work
> being
> > > >>> done
> > > >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least
> bring
> > up
> > > >>> the
> > > >>>>>>>>>>> ActiveMQ 6.0 discussion.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> With all the breaking changes currently targeted for
> version
> > > >>> 5.19.x, such
> > > >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> > > >>> Spring and Jetty
> > > >>>>>>>>>>> upgrades and now potentially major OSGi changes, it makes
> > zero
> > > >>> sense to me
> > > >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> > > >>> completely
> > > >>>>>>>>>>> incompatible with the previous version 5.18.x. Users are
> > likely
> > > >>> going to be
> > > >>>>>>>>>>> in for a rude awakening when trying to upgrade and will be
> > > >>> quite confused
> > > >>>>>>>>>>> as to why so much is different.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> The Jakarta changes should really be a major version
> upgrade
> > so
> > > >>> that it's
> > > >>>>>>>>>>> much more clear to users that it's very different from the
> > > >>> previous
> > > >>>>>>>>>>> version. Another major benefit of going with version 6.0 is
> > > >>> that it frees
> > > >>>>>>>>>>> up the previous javax releases to continue on with 5.19 or
> > 5.20
> > > >>> because we
> > > >>>>>>>>>>> will likely need to support the older javax releases for
> > quite
> > > >>> a while.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Also, from my point of view it seems pretty clear that the
> > > >>> original goal
> > > >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> > > >>> Artemis has had
> > > >>>>>>>>>>> its own branding and versioning for several years now and
> > will
> > > >>> likely
> > > >>>>>>>>>>> continue that way and not change so I don't really see that
> > as
> > > >>> a reason to
> > > >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking
> changes.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Anyways, I figure there won't be much agreement here but
> > > >>> thought I should
> > > >>>>>>>>>>> at least throw it out there before we go and release 5.19.x
> > > >>> with such major
> > > >>>>>>>>>>> breaking changes.
> > > >>>>>>>>>>>
> > > >>>>>>> --
> > > >>>>>>> --
> > > >>>>>>> François
> > > >>>>>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Same, when I have to mention both in the same discussion, I tend to add
"classic" for ActiveMQ to make sure there is no confusion with Artemis.
But that's basically it.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef <ar...@apache.org> wrote:

> As a general practice, I try to avoid unqualified + qualified names
> together - it gets confusing.  However, in this case, we have a
> long-established history.
>
> I believe that a formal rename of ActiveMQ would be fairly disruptive for a
> small amount of value.
>
> For the record - I have heard, and started using, the term "ActiveMQ
> Classic" when talking about ActiveMQ + Artemis in the same discussion.
>
> Art
>
>
> On Tue, Sep 12, 2023 at 1:52 PM David Blevins <da...@gmail.com>
> wrote:
>
> >
> >
> > > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jg...@apache.org>
> wrote:
> > >
> > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > referred to as classic.  Most of our users just say "ActiveMQ" or
> "Artemis".
> >
> > Same.  I've never heard anyone contact us and say "Classic".  Always just
> > "ActiveMQ" and "Artemis"
> >
> >
> > -David
> >
> > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > >> I don't really see a need for "Classic" and I think it should be
> > dropped.
> > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > >>
> > >> ActiveMQ Artemis has had its own versioning and brand since the
> > beginning
> > >> going back many years so I don't think getting rid of "Classic" is an
> > issue
> > >> or would lead to any confusion since as I said, no one uses it
> anyways.
> > >>
> > >> So I think it makes sense to just go with what JB said for now:
> > >>
> > >> - ActiveMQ 5.18.x
> > >> - ActiveMQ 6.x.x
> > >> - ActiveMQ 7.x.x
> > >> - ActiveMQ Artemis 2.x
> > >> - ActiveMQ Artemis 3.x
> > >>
> > >> That would be quite clear as to what each version is.
> > >>
> > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <jb@nanthrax.net
> >
> > >> wrote:
> > >>
> > >>> That makes lot of sense to me ! We will have:
> > >>>
> > >>> - ActiveMQ 5.18.x
> > >>> - ActiveMQ 6.x.x
> > >>> - ActiveMQ 7.x.x
> > >>> - ActiveMQ Artemis 2.x
> > >>> - ActiveMQ Artemis 3.x
> > >>>
> > >>> So, I propose to have two "spaces" on website:
> > >>> http://activemq.apache.org/activemq
> > >>> http://activemq.apache.org/artemis
> > >>>
> > >>> The index.html will list the two spaces and users will go to one or
> > >>> another.
> > >>>
> > >>> Thoughts ?
> > >>>
> > >>> Regards
> > >>> JB
> > >>>
> > >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> > robbie.gemmell@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > >>>>
> > >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > >>>> <fr...@openobject.fr> wrote:
> > >>>>>
> > >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > >>>>>
> > >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x like
> > >>> below,
> > >>>>>> and ActiveMQ Artemis.
> > >>>>>>
> > >>>>>> Same as last time this was discussed, I dont consider "Classic"
> part
> > >>>>>> of the actual name, just a reflective description label, quoted
> for
> > a
> > >>>>>> reason.
> > >>>>>>
> > >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > >>>>>>> Why not simply ActiveMQ and Artemis?
> > >>>>>>>
> > >>>>>>> This is how people used to name the 2 projects, I never eared
> > >>> someone
> > >>>>>>> say "ActiveMQ Classic".
> > >>>>>>>
> > >>>>>>> regards,
> > >>>>>>>
> > >>>>>>> François
> > >>>>>>>
> > >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > >>>>>>>> Same thoughts as last time you proposed it really. Adding Leto
> > >>> would
> > >>>>>>>> not be an improvement for me, more actually the reverse. I think
> > >>> it's
> > >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > >>>>>>>> confusing. Describing something as 'classic' is a pretty normal
> /
> > >>>>>>>> well-known thing, I think a user even noted that on the original
> > >>>>>>>> thread.
> > >>>>>>>>
> > >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > >>> jb@nanthrax.net> wrote:
> > >>>>>>>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to
> me)
> > >>> and
> > >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> > >>>>>>>>>
> > >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the
> mother
> > >>> of
> > >>>>>>>>> Artemis in Greek mythology) to have a clear distinction between
> > >>> the
> > >>>>>>>>> two subprojects. Thoughts ? :)
> > >>>>>>>>>
> > >>>>>>>>> If it's too "sensible", please ignore :)
> > >>>>>>>>>
> > >>>>>>>>> Regards
> > >>>>>>>>> JB
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gtully@apache.org
> >
> > >>> wrote:
> > >>>>>>>>>> makes sense, but please keep a clear distinction - activemq
> > >>> classic 6.0.0
> > >>>>>>>>>> activemq X may still evolve to combine the best of both.
> > >>>>>>>>>>
> > >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> First, I realize that this thread is likely to cause a fight
> > >>> based on past
> > >>>>>>>>>>> history and probably not go anywhere, but with the work being
> > >>> done
> > >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring
> up
> > >>> the
> > >>>>>>>>>>> ActiveMQ 6.0 discussion.
> > >>>>>>>>>>>
> > >>>>>>>>>>> With all the breaking changes currently targeted for version
> > >>> 5.19.x, such
> > >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> > >>> Spring and Jetty
> > >>>>>>>>>>> upgrades and now potentially major OSGi changes, it makes
> zero
> > >>> sense to me
> > >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> > >>> completely
> > >>>>>>>>>>> incompatible with the previous version 5.18.x. Users are
> likely
> > >>> going to be
> > >>>>>>>>>>> in for a rude awakening when trying to upgrade and will be
> > >>> quite confused
> > >>>>>>>>>>> as to why so much is different.
> > >>>>>>>>>>>
> > >>>>>>>>>>> The Jakarta changes should really be a major version upgrade
> so
> > >>> that it's
> > >>>>>>>>>>> much more clear to users that it's very different from the
> > >>> previous
> > >>>>>>>>>>> version. Another major benefit of going with version 6.0 is
> > >>> that it frees
> > >>>>>>>>>>> up the previous javax releases to continue on with 5.19 or
> 5.20
> > >>> because we
> > >>>>>>>>>>> will likely need to support the older javax releases for
> quite
> > >>> a while.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Also, from my point of view it seems pretty clear that the
> > >>> original goal
> > >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> > >>> Artemis has had
> > >>>>>>>>>>> its own branding and versioning for several years now and
> will
> > >>> likely
> > >>>>>>>>>>> continue that way and not change so I don't really see that
> as
> > >>> a reason to
> > >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Anyways, I figure there won't be much agreement here but
> > >>> thought I should
> > >>>>>>>>>>> at least throw it out there before we go and release 5.19.x
> > >>> with such major
> > >>>>>>>>>>> breaking changes.
> > >>>>>>>>>>>
> > >>>>>>> --
> > >>>>>>> --
> > >>>>>>> François
> > >>>>>>>
> > >>>
> > >>
> >
> >
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Arthur Naseef <ar...@apache.org>]

As a general practice, I try to avoid unqualified + qualified names
together - it gets confusing.  However, in this case, we have a
long-established history.

I believe that a formal rename of ActiveMQ would be fairly disruptive for a
small amount of value.

For the record - I have heard, and started using, the term "ActiveMQ
Classic" when talking about ActiveMQ + Artemis in the same discussion.

Art


On Tue, Sep 12, 2023 at 1:52 PM David Blevins <da...@gmail.com>
wrote:

>
>
> > On Sep 12, 2023, at 7:15 AM, Jeff Genender <jg...@apache.org> wrote:
> >
> > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> referred to as classic.  Most of our users just say "ActiveMQ" or "Artemis".
>
> Same.  I've never heard anyone contact us and say "Classic".  Always just
> "ActiveMQ" and "Artemis"
>
>
> -David
>
> > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> >> I don't really see a need for "Classic" and I think it should be
> dropped.
> >> No one uses it and just refers to it as "ActiveMQ 5.x".
> >>
> >> ActiveMQ Artemis has had its own versioning and brand since the
> beginning
> >> going back many years so I don't think getting rid of "Classic" is an
> issue
> >> or would lead to any confusion since as I said, no one uses it anyways.
> >>
> >> So I think it makes sense to just go with what JB said for now:
> >>
> >> - ActiveMQ 5.18.x
> >> - ActiveMQ 6.x.x
> >> - ActiveMQ 7.x.x
> >> - ActiveMQ Artemis 2.x
> >> - ActiveMQ Artemis 3.x
> >>
> >> That would be quite clear as to what each version is.
> >>
> >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> wrote:
> >>
> >>> That makes lot of sense to me ! We will have:
> >>>
> >>> - ActiveMQ 5.18.x
> >>> - ActiveMQ 6.x.x
> >>> - ActiveMQ 7.x.x
> >>> - ActiveMQ Artemis 2.x
> >>> - ActiveMQ Artemis 3.x
> >>>
> >>> So, I propose to have two "spaces" on website:
> >>> http://activemq.apache.org/activemq
> >>> http://activemq.apache.org/artemis
> >>>
> >>> The index.html will list the two spaces and users will go to one or
> >>> another.
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> robbie.gemmell@gmail.com>
> >>> wrote:
> >>>>
> >>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> >>>>
> >>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> >>>> <fr...@openobject.fr> wrote:
> >>>>>
> >>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> >>>>>
> >>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
> >>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x like
> >>> below,
> >>>>>> and ActiveMQ Artemis.
> >>>>>>
> >>>>>> Same as last time this was discussed, I dont consider "Classic" part
> >>>>>> of the actual name, just a reflective description label, quoted for
> a
> >>>>>> reason.
> >>>>>>
> >>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> >>>>>>> Why not simply ActiveMQ and Artemis?
> >>>>>>>
> >>>>>>> This is how people used to name the 2 projects, I never eared
> >>> someone
> >>>>>>> say "ActiveMQ Classic".
> >>>>>>>
> >>>>>>> regards,
> >>>>>>>
> >>>>>>> François
> >>>>>>>
> >>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
> >>>>>>>> Same thoughts as last time you proposed it really. Adding Leto
> >>> would
> >>>>>>>> not be an improvement for me, more actually the reverse. I think
> >>> it's
> >>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> >>>>>>>> confusing. Describing something as 'classic' is a pretty normal /
> >>>>>>>> well-known thing, I think a user even noted that on the original
> >>>>>>>> thread.
> >>>>>>>>
> >>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> >>> jb@nanthrax.net> wrote:
> >>>>>>>>> Is it a good time to talk about ActiveMQ "Something" instead of
> >>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> >>> and
> >>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
> >>>>>>>>>
> >>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> >>> of
> >>>>>>>>> Artemis in Greek mythology) to have a clear distinction between
> >>> the
> >>>>>>>>> two subprojects. Thoughts ? :)
> >>>>>>>>>
> >>>>>>>>> If it's too "sensible", please ignore :)
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> JB
> >>>>>>>>>
> >>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> >>> wrote:
> >>>>>>>>>> makes sense, but please keep a clear distinction - activemq
> >>> classic 6.0.0
> >>>>>>>>>> activemq X may still evolve to combine the best of both.
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> First, I realize that this thread is likely to cause a fight
> >>> based on past
> >>>>>>>>>>> history and probably not go anywhere, but with the work being
> >>> done
> >>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
> >>> the
> >>>>>>>>>>> ActiveMQ 6.0 discussion.
> >>>>>>>>>>>
> >>>>>>>>>>> With all the breaking changes currently targeted for version
> >>> 5.19.x, such
> >>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> >>> Spring and Jetty
> >>>>>>>>>>> upgrades and now potentially major OSGi changes, it makes zero
> >>> sense to me
> >>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
> >>> completely
> >>>>>>>>>>> incompatible with the previous version 5.18.x. Users are likely
> >>> going to be
> >>>>>>>>>>> in for a rude awakening when trying to upgrade and will be
> >>> quite confused
> >>>>>>>>>>> as to why so much is different.
> >>>>>>>>>>>
> >>>>>>>>>>> The Jakarta changes should really be a major version upgrade so
> >>> that it's
> >>>>>>>>>>> much more clear to users that it's very different from the
> >>> previous
> >>>>>>>>>>> version. Another major benefit of going with version 6.0 is
> >>> that it frees
> >>>>>>>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> >>> because we
> >>>>>>>>>>> will likely need to support the older javax releases for quite
> >>> a while.
> >>>>>>>>>>>
> >>>>>>>>>>> Also, from my point of view it seems pretty clear that the
> >>> original goal
> >>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> >>> Artemis has had
> >>>>>>>>>>> its own branding and versioning for several years now and will
> >>> likely
> >>>>>>>>>>> continue that way and not change so I don't really see that as
> >>> a reason to
> >>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> >>>>>>>>>>>
> >>>>>>>>>>> Anyways, I figure there won't be much agreement here but
> >>> thought I should
> >>>>>>>>>>> at least throw it out there before we go and release 5.19.x
> >>> with such major
> >>>>>>>>>>> breaking changes.
> >>>>>>>>>>>
> >>>>>>> --
> >>>>>>> --
> >>>>>>> François
> >>>>>>>
> >>>
> >>
>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[David Blevins <da...@gmail.com>]

> On Sep 12, 2023, at 7:15 AM, Jeff Genender <jg...@apache.org> wrote:
> 
> +1 to what Christopher said... I have rarely heard AMQ 5.x being referred to as classic.  Most of our users just say "ActiveMQ" or "Artemis".

Same.  I've never heard anyone contact us and say "Classic".  Always just "ActiveMQ" and "Artemis"


-David

> On 2023/09/12 13:44:15 Christopher Shannon wrote:
>> I don't really see a need for "Classic" and I think it should be dropped.
>> No one uses it and just refers to it as "ActiveMQ 5.x".
>> 
>> ActiveMQ Artemis has had its own versioning and brand since the beginning
>> going back many years so I don't think getting rid of "Classic" is an issue
>> or would lead to any confusion since as I said, no one uses it anyways.
>> 
>> So I think it makes sense to just go with what JB said for now:
>> 
>> - ActiveMQ 5.18.x
>> - ActiveMQ 6.x.x
>> - ActiveMQ 7.x.x
>> - ActiveMQ Artemis 2.x
>> - ActiveMQ Artemis 3.x
>> 
>> That would be quite clear as to what each version is.
>> 
>> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>> 
>>> That makes lot of sense to me ! We will have:
>>> 
>>> - ActiveMQ 5.18.x
>>> - ActiveMQ 6.x.x
>>> - ActiveMQ 7.x.x
>>> - ActiveMQ Artemis 2.x
>>> - ActiveMQ Artemis 3.x
>>> 
>>> So, I propose to have two "spaces" on website:
>>> http://activemq.apache.org/activemq
>>> http://activemq.apache.org/artemis
>>> 
>>> The index.html will list the two spaces and users will go to one or
>>> another.
>>> 
>>> Thoughts ?
>>> 
>>> Regards
>>> JB
>>> 
>>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
>>> wrote:
>>>> 
>>>> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
>>>> 
>>>> On Tue, 12 Sept 2023 at 13:34, Francois Papon
>>>> <fr...@openobject.fr> wrote:
>>>>> 
>>>>> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
>>>>> 
>>>>> On 12/09/2023 14:14, Robbie Gemmell wrote:
>>>>>> That is how I refer to them, or more fully as ActiveMQ 5.x like
>>> below,
>>>>>> and ActiveMQ Artemis.
>>>>>> 
>>>>>> Same as last time this was discussed, I dont consider "Classic" part
>>>>>> of the actual name, just a reflective description label, quoted for a
>>>>>> reason.
>>>>>> 
>>>>>> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
>>>>>>> Why not simply ActiveMQ and Artemis?
>>>>>>> 
>>>>>>> This is how people used to name the 2 projects, I never eared
>>> someone
>>>>>>> say "ActiveMQ Classic".
>>>>>>> 
>>>>>>> regards,
>>>>>>> 
>>>>>>> François
>>>>>>> 
>>>>>>> On 12/09/2023 13:07, Robbie Gemmell wrote:
>>>>>>>> Same thoughts as last time you proposed it really. Adding Leto
>>> would
>>>>>>>> not be an improvement for me, more actually the reverse. I think
>>> it's
>>>>>>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
>>>>>>>> confusing. Describing something as 'classic' is a pretty normal /
>>>>>>>> well-known thing, I think a user even noted that on the original
>>>>>>>> thread.
>>>>>>>> 
>>>>>>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
>>> jb@nanthrax.net> wrote:
>>>>>>>>> Is it a good time to talk about ActiveMQ "Something" instead of
>>>>>>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
>>> and
>>>>>>>>> most of people uses simply Artemis and ActiveMQ as name)
>>>>>>>>> 
>>>>>>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
>>> of
>>>>>>>>> Artemis in Greek mythology) to have a clear distinction between
>>> the
>>>>>>>>> two subprojects. Thoughts ? :)
>>>>>>>>> 
>>>>>>>>> If it's too "sensible", please ignore :)
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>> 
>>>>>>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
>>> wrote:
>>>>>>>>>> makes sense, but please keep a clear distinction - activemq
>>> classic 6.0.0
>>>>>>>>>> activemq X may still evolve to combine the best of both.
>>>>>>>>>> 
>>>>>>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
>>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> First, I realize that this thread is likely to cause a fight
>>> based on past
>>>>>>>>>>> history and probably not go anywhere, but with the work being
>>> done
>>>>>>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
>>> the
>>>>>>>>>>> ActiveMQ 6.0 discussion.
>>>>>>>>>>> 
>>>>>>>>>>> With all the breaking changes currently targeted for version
>>> 5.19.x, such
>>>>>>>>>>> as the Jakarta switch from javax, requiring JDK 17, major
>>> Spring and Jetty
>>>>>>>>>>> upgrades and now potentially major OSGi changes, it makes zero
>>> sense to me
>>>>>>>>>>> to have this next AMQ version as version 5.19.0 as it's
>>> completely
>>>>>>>>>>> incompatible with the previous version 5.18.x. Users are likely
>>> going to be
>>>>>>>>>>> in for a rude awakening when trying to upgrade and will be
>>> quite confused
>>>>>>>>>>> as to why so much is different.
>>>>>>>>>>> 
>>>>>>>>>>> The Jakarta changes should really be a major version upgrade so
>>> that it's
>>>>>>>>>>> much more clear to users that it's very different from the
>>> previous
>>>>>>>>>>> version. Another major benefit of going with version 6.0 is
>>> that it frees
>>>>>>>>>>> up the previous javax releases to continue on with 5.19 or 5.20
>>> because we
>>>>>>>>>>> will likely need to support the older javax releases for quite
>>> a while.
>>>>>>>>>>> 
>>>>>>>>>>> Also, from my point of view it seems pretty clear that the
>>> original goal
>>>>>>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
>>> Artemis has had
>>>>>>>>>>> its own branding and versioning for several years now and will
>>> likely
>>>>>>>>>>> continue that way and not change so I don't really see that as
>>> a reason to
>>>>>>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>>>>>>>>>>> 
>>>>>>>>>>> Anyways, I figure there won't be much agreement here but
>>> thought I should
>>>>>>>>>>> at least throw it out there before we go and release 5.19.x
>>> with such major
>>>>>>>>>>> breaking changes.
>>>>>>>>>>> 
>>>>>>> --
>>>>>>> --
>>>>>>> François
>>>>>>> 
>>> 
>> 

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jeff Genender <jg...@apache.org>]

+1 to what Christopher said... I have rarely heard AMQ 5.x being referred to as classic.  Most of our users just say "ActiveMQ" or "Artemis".

Jeff


On 2023/09/12 13:44:15 Christopher Shannon wrote:
> I don't really see a need for "Classic" and I think it should be dropped.
> No one uses it and just refers to it as "ActiveMQ 5.x".
> 
> ActiveMQ Artemis has had its own versioning and brand since the beginning
> going back many years so I don't think getting rid of "Classic" is an issue
> or would lead to any confusion since as I said, no one uses it anyways.
> 
> So I think it makes sense to just go with what JB said for now:
> 
> - ActiveMQ 5.18.x
> - ActiveMQ 6.x.x
> - ActiveMQ 7.x.x
> - ActiveMQ Artemis 2.x
> - ActiveMQ Artemis 3.x
> 
> That would be quite clear as to what each version is.
> 
> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> 
> > That makes lot of sense to me ! We will have:
> >
> > - ActiveMQ 5.18.x
> > - ActiveMQ 6.x.x
> > - ActiveMQ 7.x.x
> > - ActiveMQ Artemis 2.x
> > - ActiveMQ Artemis 3.x
> >
> > So, I propose to have two "spaces" on website:
> > http://activemq.apache.org/activemq
> > http://activemq.apache.org/artemis
> >
> > The index.html will list the two spaces and users will go to one or
> > another.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> > >
> > > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > >
> > > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > <fr...@openobject.fr> wrote:
> > > >
> > > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > >
> > > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> > below,
> > > > > and ActiveMQ Artemis.
> > > > >
> > > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > > of the actual name, just a reflective description label, quoted for a
> > > > > reason.
> > > > >
> > > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > > >> Why not simply ActiveMQ and Artemis?
> > > > >>
> > > > >> This is how people used to name the 2 projects, I never eared
> > someone
> > > > >> say "ActiveMQ Classic".
> > > > >>
> > > > >> regards,
> > > > >>
> > > > >> François
> > > > >>
> > > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > >>> Same thoughts as last time you proposed it really. Adding Leto
> > would
> > > > >>> not be an improvement for me, more actually the reverse. I think
> > it's
> > > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > > >>> well-known thing, I think a user even noted that on the original
> > > > >>> thread.
> > > > >>>
> > > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > jb@nanthrax.net> wrote:
> > > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> > and
> > > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > >>>>
> > > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> > of
> > > > >>>> Artemis in Greek mythology) to have a clear distinction between
> > the
> > > > >>>> two subprojects. Thoughts ? :)
> > > > >>>>
> > > > >>>> If it's too "sensible", please ignore :)
> > > > >>>>
> > > > >>>> Regards
> > > > >>>> JB
> > > > >>>>
> > > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> > wrote:
> > > > >>>>> makes sense, but please keep a clear distinction - activemq
> > classic 6.0.0
> > > > >>>>> activemq X may still evolve to combine the best of both.
> > > > >>>>>
> > > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > > >>>>>
> > > > >>>>>> First, I realize that this thread is likely to cause a fight
> > based on past
> > > > >>>>>> history and probably not go anywhere, but with the work being
> > done
> > > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
> > the
> > > > >>>>>> ActiveMQ 6.0 discussion.
> > > > >>>>>>
> > > > >>>>>> With all the breaking changes currently targeted for version
> > 5.19.x, such
> > > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> > Spring and Jetty
> > > > >>>>>> upgrades and now potentially major OSGi changes, it makes zero
> > sense to me
> > > > >>>>>> to have this next AMQ version as version 5.19.0 as it's
> > completely
> > > > >>>>>> incompatible with the previous version 5.18.x. Users are likely
> > going to be
> > > > >>>>>> in for a rude awakening when trying to upgrade and will be
> > quite confused
> > > > >>>>>> as to why so much is different.
> > > > >>>>>>
> > > > >>>>>> The Jakarta changes should really be a major version upgrade so
> > that it's
> > > > >>>>>> much more clear to users that it's very different from the
> > previous
> > > > >>>>>> version. Another major benefit of going with version 6.0 is
> > that it frees
> > > > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> > because we
> > > > >>>>>> will likely need to support the older javax releases for quite
> > a while.
> > > > >>>>>>
> > > > >>>>>> Also, from my point of view it seems pretty clear that the
> > original goal
> > > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> > Artemis has had
> > > > >>>>>> its own branding and versioning for several years now and will
> > likely
> > > > >>>>>> continue that way and not change so I don't really see that as
> > a reason to
> > > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > > >>>>>>
> > > > >>>>>> Anyways, I figure there won't be much agreement here but
> > thought I should
> > > > >>>>>> at least throw it out there before we go and release 5.19.x
> > with such major
> > > > >>>>>> breaking changes.
> > > > >>>>>>
> > > > >> --
> > > > >> --
> > > > >> François
> > > > >>
> >
> 

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Christopher Shannon <ch...@gmail.com>]

I don't really see a need for "Classic" and I think it should be dropped.
No one uses it and just refers to it as "ActiveMQ 5.x".

ActiveMQ Artemis has had its own versioning and brand since the beginning
going back many years so I don't think getting rid of "Classic" is an issue
or would lead to any confusion since as I said, no one uses it anyways.

So I think it makes sense to just go with what JB said for now:

- ActiveMQ 5.18.x
- ActiveMQ 6.x.x
- ActiveMQ 7.x.x
- ActiveMQ Artemis 2.x
- ActiveMQ Artemis 3.x

That would be quite clear as to what each version is.

On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> That makes lot of sense to me ! We will have:
>
> - ActiveMQ 5.18.x
> - ActiveMQ 6.x.x
> - ActiveMQ 7.x.x
> - ActiveMQ Artemis 2.x
> - ActiveMQ Artemis 3.x
>
> So, I propose to have two "spaces" on website:
> http://activemq.apache.org/activemq
> http://activemq.apache.org/artemis
>
> The index.html will list the two spaces and users will go to one or
> another.
>
> Thoughts ?
>
> Regards
> JB
>
> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
> >
> > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> >
> > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > <fr...@openobject.fr> wrote:
> > >
> > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > >
> > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> below,
> > > > and ActiveMQ Artemis.
> > > >
> > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > of the actual name, just a reflective description label, quoted for a
> > > > reason.
> > > >
> > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > >> Why not simply ActiveMQ and Artemis?
> > > >>
> > > >> This is how people used to name the 2 projects, I never eared
> someone
> > > >> say "ActiveMQ Classic".
> > > >>
> > > >> regards,
> > > >>
> > > >> François
> > > >>
> > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > >>> Same thoughts as last time you proposed it really. Adding Leto
> would
> > > >>> not be an improvement for me, more actually the reverse. I think
> it's
> > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > >>> well-known thing, I think a user even noted that on the original
> > > >>> thread.
> > > >>>
> > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> jb@nanthrax.net> wrote:
> > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> and
> > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > >>>>
> > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> of
> > > >>>> Artemis in Greek mythology) to have a clear distinction between
> the
> > > >>>> two subprojects. Thoughts ? :)
> > > >>>>
> > > >>>> If it's too "sensible", please ignore :)
> > > >>>>
> > > >>>> Regards
> > > >>>> JB
> > > >>>>
> > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> wrote:
> > > >>>>> makes sense, but please keep a clear distinction - activemq
> classic 6.0.0
> > > >>>>> activemq X may still evolve to combine the best of both.
> > > >>>>>
> > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > >>>>>
> > > >>>>>> First, I realize that this thread is likely to cause a fight
> based on past
> > > >>>>>> history and probably not go anywhere, but with the work being
> done
> > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
> the
> > > >>>>>> ActiveMQ 6.0 discussion.
> > > >>>>>>
> > > >>>>>> With all the breaking changes currently targeted for version
> 5.19.x, such
> > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> Spring and Jetty
> > > >>>>>> upgrades and now potentially major OSGi changes, it makes zero
> sense to me
> > > >>>>>> to have this next AMQ version as version 5.19.0 as it's
> completely
> > > >>>>>> incompatible with the previous version 5.18.x. Users are likely
> going to be
> > > >>>>>> in for a rude awakening when trying to upgrade and will be
> quite confused
> > > >>>>>> as to why so much is different.
> > > >>>>>>
> > > >>>>>> The Jakarta changes should really be a major version upgrade so
> that it's
> > > >>>>>> much more clear to users that it's very different from the
> previous
> > > >>>>>> version. Another major benefit of going with version 6.0 is
> that it frees
> > > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> because we
> > > >>>>>> will likely need to support the older javax releases for quite
> a while.
> > > >>>>>>
> > > >>>>>> Also, from my point of view it seems pretty clear that the
> original goal
> > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> Artemis has had
> > > >>>>>> its own branding and versioning for several years now and will
> likely
> > > >>>>>> continue that way and not change so I don't really see that as
> a reason to
> > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > >>>>>>
> > > >>>>>> Anyways, I figure there won't be much agreement here but
> thought I should
> > > >>>>>> at least throw it out there before we go and release 5.19.x
> with such major
> > > >>>>>> breaking changes.
> > > >>>>>>
> > > >> --
> > > >> --
> > > >> François
> > > >>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Justin

My point is not about the URL (absolutely right we can use our
existing URLs using "components"
https://activemq.apache.org/components/classic/
https://activemq.apache.org/components/artemis/ etc). My point is more
in the content and look'n feel. I think we should restyle/rework the
documentation:
- new more pro & sexy look'n feel
- verifying/updating content
- adding some more kind of examples/use cases

Regards
JB

On Tue, Sep 12, 2023 at 4:03 PM Justin Bertram <jb...@apache.org> wrote:
>
> I still think it's important to have some kind of specific name or tag
> (e.g. "Classic") to differentiate the two brokers, especially on the
> website where the two are "next to" each other. Using a version number just
> doesn't cut it in my opinion. For example, what happens when Artemis'
> version number catches up to 6.x, etc.? You won't be able to use the
> version number anymore to differentiate the two.
>
> Clarity is really important for everyone in the community - especially in
> support scenarios. I work a lot on Stack Overflow with folks using both
> brokers and having a verbal umbrella for each is extremely helpful.
>
>
> Justin
>
> On Tue, Sep 12, 2023 at 8:35 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > That makes lot of sense to me ! We will have:
> >
> > - ActiveMQ 5.18.x
> > - ActiveMQ 6.x.x
> > - ActiveMQ 7.x.x
> > - ActiveMQ Artemis 2.x
> > - ActiveMQ Artemis 3.x
> >
> > So, I propose to have two "spaces" on website:
> > http://activemq.apache.org/activemq
> > http://activemq.apache.org/artemis
> >
> > The index.html will list the two spaces and users will go to one or
> > another.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> > >
> > > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > >
> > > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > <fr...@openobject.fr> wrote:
> > > >
> > > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > >
> > > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> > below,
> > > > > and ActiveMQ Artemis.
> > > > >
> > > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > > of the actual name, just a reflective description label, quoted for a
> > > > > reason.
> > > > >
> > > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > > >> Why not simply ActiveMQ and Artemis?
> > > > >>
> > > > >> This is how people used to name the 2 projects, I never eared
> > someone
> > > > >> say "ActiveMQ Classic".
> > > > >>
> > > > >> regards,
> > > > >>
> > > > >> François
> > > > >>
> > > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > >>> Same thoughts as last time you proposed it really. Adding Leto
> > would
> > > > >>> not be an improvement for me, more actually the reverse. I think
> > it's
> > > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > > >>> well-known thing, I think a user even noted that on the original
> > > > >>> thread.
> > > > >>>
> > > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > jb@nanthrax.net> wrote:
> > > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> > and
> > > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > >>>>
> > > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> > of
> > > > >>>> Artemis in Greek mythology) to have a clear distinction between
> > the
> > > > >>>> two subprojects. Thoughts ? :)
> > > > >>>>
> > > > >>>> If it's too "sensible", please ignore :)
> > > > >>>>
> > > > >>>> Regards
> > > > >>>> JB
> > > > >>>>
> > > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> > wrote:
> > > > >>>>> makes sense, but please keep a clear distinction - activemq
> > classic 6.0.0
> > > > >>>>> activemq X may still evolve to combine the best of both.
> > > > >>>>>
> > > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > > >>>>>
> > > > >>>>>> First, I realize that this thread is likely to cause a fight
> > based on past
> > > > >>>>>> history and probably not go anywhere, but with the work being
> > done
> > > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
> > the
> > > > >>>>>> ActiveMQ 6.0 discussion.
> > > > >>>>>>
> > > > >>>>>> With all the breaking changes currently targeted for version
> > 5.19.x, such
> > > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> > Spring and Jetty
> > > > >>>>>> upgrades and now potentially major OSGi changes, it makes zero
> > sense to me
> > > > >>>>>> to have this next AMQ version as version 5.19.0 as it's
> > completely
> > > > >>>>>> incompatible with the previous version 5.18.x. Users are likely
> > going to be
> > > > >>>>>> in for a rude awakening when trying to upgrade and will be
> > quite confused
> > > > >>>>>> as to why so much is different.
> > > > >>>>>>
> > > > >>>>>> The Jakarta changes should really be a major version upgrade so
> > that it's
> > > > >>>>>> much more clear to users that it's very different from the
> > previous
> > > > >>>>>> version. Another major benefit of going with version 6.0 is
> > that it frees
> > > > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> > because we
> > > > >>>>>> will likely need to support the older javax releases for quite
> > a while.
> > > > >>>>>>
> > > > >>>>>> Also, from my point of view it seems pretty clear that the
> > original goal
> > > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> > Artemis has had
> > > > >>>>>> its own branding and versioning for several years now and will
> > likely
> > > > >>>>>> continue that way and not change so I don't really see that as
> > a reason to
> > > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > > >>>>>>
> > > > >>>>>> Anyways, I figure there won't be much agreement here but
> > thought I should
> > > > >>>>>> at least throw it out there before we go and release 5.19.x
> > with such major
> > > > >>>>>> breaking changes.
> > > > >>>>>>
> > > > >> --
> > > > >> --
> > > > >> François
> > > > >>
> >
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Justin Bertram <jb...@apache.org>]

I still think it's important to have some kind of specific name or tag
(e.g. "Classic") to differentiate the two brokers, especially on the
website where the two are "next to" each other. Using a version number just
doesn't cut it in my opinion. For example, what happens when Artemis'
version number catches up to 6.x, etc.? You won't be able to use the
version number anymore to differentiate the two.

Clarity is really important for everyone in the community - especially in
support scenarios. I work a lot on Stack Overflow with folks using both
brokers and having a verbal umbrella for each is extremely helpful.


Justin

On Tue, Sep 12, 2023 at 8:35 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> That makes lot of sense to me ! We will have:
>
> - ActiveMQ 5.18.x
> - ActiveMQ 6.x.x
> - ActiveMQ 7.x.x
> - ActiveMQ Artemis 2.x
> - ActiveMQ Artemis 3.x
>
> So, I propose to have two "spaces" on website:
> http://activemq.apache.org/activemq
> http://activemq.apache.org/artemis
>
> The index.html will list the two spaces and users will go to one or
> another.
>
> Thoughts ?
>
> Regards
> JB
>
> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
> >
> > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> >
> > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > <fr...@openobject.fr> wrote:
> > >
> > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > >
> > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> below,
> > > > and ActiveMQ Artemis.
> > > >
> > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > of the actual name, just a reflective description label, quoted for a
> > > > reason.
> > > >
> > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > >> Why not simply ActiveMQ and Artemis?
> > > >>
> > > >> This is how people used to name the 2 projects, I never eared
> someone
> > > >> say "ActiveMQ Classic".
> > > >>
> > > >> regards,
> > > >>
> > > >> François
> > > >>
> > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > >>> Same thoughts as last time you proposed it really. Adding Leto
> would
> > > >>> not be an improvement for me, more actually the reverse. I think
> it's
> > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > >>> well-known thing, I think a user even noted that on the original
> > > >>> thread.
> > > >>>
> > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> jb@nanthrax.net> wrote:
> > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> and
> > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > >>>>
> > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> of
> > > >>>> Artemis in Greek mythology) to have a clear distinction between
> the
> > > >>>> two subprojects. Thoughts ? :)
> > > >>>>
> > > >>>> If it's too "sensible", please ignore :)
> > > >>>>
> > > >>>> Regards
> > > >>>> JB
> > > >>>>
> > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> wrote:
> > > >>>>> makes sense, but please keep a clear distinction - activemq
> classic 6.0.0
> > > >>>>> activemq X may still evolve to combine the best of both.
> > > >>>>>
> > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > >>>>>
> > > >>>>>> First, I realize that this thread is likely to cause a fight
> based on past
> > > >>>>>> history and probably not go anywhere, but with the work being
> done
> > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
> the
> > > >>>>>> ActiveMQ 6.0 discussion.
> > > >>>>>>
> > > >>>>>> With all the breaking changes currently targeted for version
> 5.19.x, such
> > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> Spring and Jetty
> > > >>>>>> upgrades and now potentially major OSGi changes, it makes zero
> sense to me
> > > >>>>>> to have this next AMQ version as version 5.19.0 as it's
> completely
> > > >>>>>> incompatible with the previous version 5.18.x. Users are likely
> going to be
> > > >>>>>> in for a rude awakening when trying to upgrade and will be
> quite confused
> > > >>>>>> as to why so much is different.
> > > >>>>>>
> > > >>>>>> The Jakarta changes should really be a major version upgrade so
> that it's
> > > >>>>>> much more clear to users that it's very different from the
> previous
> > > >>>>>> version. Another major benefit of going with version 6.0 is
> that it frees
> > > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> because we
> > > >>>>>> will likely need to support the older javax releases for quite
> a while.
> > > >>>>>>
> > > >>>>>> Also, from my point of view it seems pretty clear that the
> original goal
> > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> Artemis has had
> > > >>>>>> its own branding and versioning for several years now and will
> likely
> > > >>>>>> continue that way and not change so I don't really see that as
> a reason to
> > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > >>>>>>
> > > >>>>>> Anyways, I figure there won't be much agreement here but
> thought I should
> > > >>>>>> at least throw it out there before we go and release 5.19.x
> with such major
> > > >>>>>> breaking changes.
> > > >>>>>>
> > > >> --
> > > >> --
> > > >> François
> > > >>
>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jonathan Gallimore <jo...@gmail.com>]

+1

Thanks

Jon

On Tue, Sep 12, 2023 at 2:27 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> That makes lot of sense to me ! We will have:
>
> - ActiveMQ 5.18.x
> - ActiveMQ 6.x.x
> - ActiveMQ 7.x.x
> - ActiveMQ Artemis 2.x
> - ActiveMQ Artemis 3.x
>
> So, I propose to have two "spaces" on website:
> http://activemq.apache.org/activemq
> http://activemq.apache.org/artemis
>
> The index.html will list the two spaces and users will go to one or
> another.
>
> Thoughts ?
>
> Regards
> JB
>
> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
> >
> > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> >
> > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > <fr...@openobject.fr> wrote:
> > >
> > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > >
> > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> below,
> > > > and ActiveMQ Artemis.
> > > >
> > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > of the actual name, just a reflective description label, quoted for a
> > > > reason.
> > > >
> > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > >> Why not simply ActiveMQ and Artemis?
> > > >>
> > > >> This is how people used to name the 2 projects, I never eared
> someone
> > > >> say "ActiveMQ Classic".
> > > >>
> > > >> regards,
> > > >>
> > > >> François
> > > >>
> > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > >>> Same thoughts as last time you proposed it really. Adding Leto
> would
> > > >>> not be an improvement for me, more actually the reverse. I think
> it's
> > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > >>> well-known thing, I think a user even noted that on the original
> > > >>> thread.
> > > >>>
> > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> jb@nanthrax.net> wrote:
> > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> and
> > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > >>>>
> > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> of
> > > >>>> Artemis in Greek mythology) to have a clear distinction between
> the
> > > >>>> two subprojects. Thoughts ? :)
> > > >>>>
> > > >>>> If it's too "sensible", please ignore :)
> > > >>>>
> > > >>>> Regards
> > > >>>> JB
> > > >>>>
> > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> wrote:
> > > >>>>> makes sense, but please keep a clear distinction - activemq
> classic 6.0.0
> > > >>>>> activemq X may still evolve to combine the best of both.
> > > >>>>>
> > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > >>>>>
> > > >>>>>> First, I realize that this thread is likely to cause a fight
> based on past
> > > >>>>>> history and probably not go anywhere, but with the work being
> done
> > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up
> the
> > > >>>>>> ActiveMQ 6.0 discussion.
> > > >>>>>>
> > > >>>>>> With all the breaking changes currently targeted for version
> 5.19.x, such
> > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> Spring and Jetty
> > > >>>>>> upgrades and now potentially major OSGi changes, it makes zero
> sense to me
> > > >>>>>> to have this next AMQ version as version 5.19.0 as it's
> completely
> > > >>>>>> incompatible with the previous version 5.18.x. Users are likely
> going to be
> > > >>>>>> in for a rude awakening when trying to upgrade and will be
> quite confused
> > > >>>>>> as to why so much is different.
> > > >>>>>>
> > > >>>>>> The Jakarta changes should really be a major version upgrade so
> that it's
> > > >>>>>> much more clear to users that it's very different from the
> previous
> > > >>>>>> version. Another major benefit of going with version 6.0 is
> that it frees
> > > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20
> because we
> > > >>>>>> will likely need to support the older javax releases for quite
> a while.
> > > >>>>>>
> > > >>>>>> Also, from my point of view it seems pretty clear that the
> original goal
> > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> Artemis has had
> > > >>>>>> its own branding and versioning for several years now and will
> likely
> > > >>>>>> continue that way and not change so I don't really see that as
> a reason to
> > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > >>>>>>
> > > >>>>>> Anyways, I figure there won't be much agreement here but
> thought I should
> > > >>>>>> at least throw it out there before we go and release 5.19.x
> with such major
> > > >>>>>> breaking changes.
> > > >>>>>>
> > > >> --
> > > >> --
> > > >> François
> > > >>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Christopher Shannon <ch...@gmail.com>]

If Artemis were to reach a version 5 or version 6 I don't think there would
be any confusion. Realistically, no one is going to refer to it as
"ActiveMQ 5" or "ActiveMQ 6". They are going to say "Artemis 5" or "Artemis
6".

Anyways, this is now getting a bit off topic. I don't want to keep
derailing the main point of the thread which is we just need to bump the
versioning to 6.0.0 before we continue with the release so let's focus on
that.

Stuff like whether we drop "Classic" or anything else (like website stuff)
should just go into a different thread as there are going to be different
opinions on it. At the end of the day if we have to keep "Classic"
because we don't agree then at least we can bump the major version to 6.0.0

On Tue, Sep 12, 2023 at 10:26 AM Robbie Gemmell <ro...@gmail.com>
wrote:

> We already have 4 component spaces on the site which has operated like
> that for years. I dont think http://activemq.apache.org/activemq is
> particularly an improvement or more obvious than whats there now,
> personally. The site did used to use /artemis but changed away from
> that to the current components arrangement a while ago.
>
> Overall I'd rather spend less time repeating this same URL naming
> discussion, so more was spent improving the actual content sitting in
> (or still outside) the spaces that have existed for years.
>
> On Tue, 12 Sept 2023 at 14:27, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> > That makes lot of sense to me ! We will have:
> >
> > - ActiveMQ 5.18.x
> > - ActiveMQ 6.x.x
> > - ActiveMQ 7.x.x
> > - ActiveMQ Artemis 2.x
> > - ActiveMQ Artemis 3.x
> >
> > So, I propose to have two "spaces" on website:
> > http://activemq.apache.org/activemq
> > http://activemq.apache.org/artemis
> >
> > The index.html will list the two spaces and users will go to one or
> another.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
> > >
> > > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > >
> > > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > > <fr...@openobject.fr> wrote:
> > > >
> > > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > >
> > > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> below,
> > > > > and ActiveMQ Artemis.
> > > > >
> > > > > Same as last time this was discussed, I dont consider "Classic"
> part
> > > > > of the actual name, just a reflective description label, quoted
> for a
> > > > > reason.
> > > > >
> > > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > > >> Why not simply ActiveMQ and Artemis?
> > > > >>
> > > > >> This is how people used to name the 2 projects, I never eared
> someone
> > > > >> say "ActiveMQ Classic".
> > > > >>
> > > > >> regards,
> > > > >>
> > > > >> François
> > > > >>
> > > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > >>> Same thoughts as last time you proposed it really. Adding Leto
> would
> > > > >>> not be an improvement for me, more actually the reverse. I think
> it's
> > > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > > >>> well-known thing, I think a user even noted that on the original
> > > > >>> thread.
> > > > >>>
> > > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> jb@nanthrax.net> wrote:
> > > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to
> me) and
> > > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > >>>>
> > > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the
> mother of
> > > > >>>> Artemis in Greek mythology) to have a clear distinction between
> the
> > > > >>>> two subprojects. Thoughts ? :)
> > > > >>>>
> > > > >>>> If it's too "sensible", please ignore :)
> > > > >>>>
> > > > >>>> Regards
> > > > >>>> JB
> > > > >>>>
> > > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org>
> wrote:
> > > > >>>>> makes sense, but please keep a clear distinction - activemq
> classic 6.0.0
> > > > >>>>> activemq X may still evolve to combine the best of both.
> > > > >>>>>
> > > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > > >>>>>
> > > > >>>>>> First, I realize that this thread is likely to cause a fight
> based on past
> > > > >>>>>> history and probably not go anywhere, but with the work being
> done
> > > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring
> up the
> > > > >>>>>> ActiveMQ 6.0 discussion.
> > > > >>>>>>
> > > > >>>>>> With all the breaking changes currently targeted for version
> 5.19.x, such
> > > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major
> Spring and Jetty
> > > > >>>>>> upgrades and now potentially major OSGi changes, it makes
> zero sense to me
> > > > >>>>>> to have this next AMQ version as version 5.19.0 as it's
> completely
> > > > >>>>>> incompatible with the previous version 5.18.x. Users are
> likely going to be
> > > > >>>>>> in for a rude awakening when trying to upgrade and will be
> quite confused
> > > > >>>>>> as to why so much is different.
> > > > >>>>>>
> > > > >>>>>> The Jakarta changes should really be a major version upgrade
> so that it's
> > > > >>>>>> much more clear to users that it's very different from the
> previous
> > > > >>>>>> version. Another major benefit of going with version 6.0 is
> that it frees
> > > > >>>>>> up the previous javax releases to continue on with 5.19 or
> 5.20 because we
> > > > >>>>>> will likely need to support the older javax releases for
> quite a while.
> > > > >>>>>>
> > > > >>>>>> Also, from my point of view it seems pretty clear that the
> original goal
> > > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.
> Artemis has had
> > > > >>>>>> its own branding and versioning for several years now and
> will likely
> > > > >>>>>> continue that way and not change so I don't really see that
> as a reason to
> > > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > > >>>>>>
> > > > >>>>>> Anyways, I figure there won't be much agreement here but
> thought I should
> > > > >>>>>> at least throw it out there before we go and release 5.19.x
> with such major
> > > > >>>>>> breaking changes.
> > > > >>>>>>
> > > > >> --
> > > > >> --
> > > > >> François
> > > > >>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

We already have 4 component spaces on the site which has operated like
that for years. I dont think http://activemq.apache.org/activemq is
particularly an improvement or more obvious than whats there now,
personally. The site did used to use /artemis but changed away from
that to the current components arrangement a while ago.

Overall I'd rather spend less time repeating this same URL naming
discussion, so more was spent improving the actual content sitting in
(or still outside) the spaces that have existed for years.

On Tue, 12 Sept 2023 at 14:27, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> That makes lot of sense to me ! We will have:
>
> - ActiveMQ 5.18.x
> - ActiveMQ 6.x.x
> - ActiveMQ 7.x.x
> - ActiveMQ Artemis 2.x
> - ActiveMQ Artemis 3.x
>
> So, I propose to have two "spaces" on website:
> http://activemq.apache.org/activemq
> http://activemq.apache.org/artemis
>
> The index.html will list the two spaces and users will go to one or another.
>
> Thoughts ?
>
> Regards
> JB
>
> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> >
> > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > <fr...@openobject.fr> wrote:
> > >
> > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > >
> > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > That is how I refer to them, or more fully as ActiveMQ 5.x like below,
> > > > and ActiveMQ Artemis.
> > > >
> > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > of the actual name, just a reflective description label, quoted for a
> > > > reason.
> > > >
> > > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > > >> Why not simply ActiveMQ and Artemis?
> > > >>
> > > >> This is how people used to name the 2 projects, I never eared someone
> > > >> say "ActiveMQ Classic".
> > > >>
> > > >> regards,
> > > >>
> > > >> François
> > > >>
> > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > >>> Same thoughts as last time you proposed it really. Adding Leto would
> > > >>> not be an improvement for me, more actually the reverse. I think it's
> > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > >>> well-known thing, I think a user even noted that on the original
> > > >>> thread.
> > > >>>
> > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
> > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > >>>>
> > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
> > > >>>> Artemis in Greek mythology) to have a clear distinction between the
> > > >>>> two subprojects. Thoughts ? :)
> > > >>>>
> > > >>>> If it's too "sensible", please ignore :)
> > > >>>>
> > > >>>> Regards
> > > >>>> JB
> > > >>>>
> > > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
> > > >>>>> makes sense, but please keep a clear distinction - activemq classic 6.0.0
> > > >>>>> activemq X may still evolve to combine the best of both.
> > > >>>>>
> > > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > > >>>>> christopher.l.shannon@gmail.com> wrote:
> > > >>>>>
> > > >>>>>> First, I realize that this thread is likely to cause a fight based on past
> > > >>>>>> history and probably not go anywhere, but with the work being done
> > > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > >>>>>> ActiveMQ 6.0 discussion.
> > > >>>>>>
> > > >>>>>> With all the breaking changes currently targeted for version 5.19.x, such
> > > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > > >>>>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
> > > >>>>>> to have this next AMQ version as version 5.19.0 as it's completely
> > > >>>>>> incompatible with the previous version 5.18.x. Users are likely going to be
> > > >>>>>> in for a rude awakening when trying to upgrade and will be quite confused
> > > >>>>>> as to why so much is different.
> > > >>>>>>
> > > >>>>>> The Jakarta changes should really be a major version upgrade so that it's
> > > >>>>>> much more clear to users that it's very different from the previous
> > > >>>>>> version. Another major benefit of going with version 6.0 is that it frees
> > > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
> > > >>>>>> will likely need to support the older javax releases for quite a while.
> > > >>>>>>
> > > >>>>>> Also, from my point of view it seems pretty clear that the original goal
> > > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > > >>>>>> its own branding and versioning for several years now and will likely
> > > >>>>>> continue that way and not change so I don't really see that as a reason to
> > > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > > >>>>>>
> > > >>>>>> Anyways, I figure there won't be much agreement here but thought I should
> > > >>>>>> at least throw it out there before we go and release 5.19.x with such major
> > > >>>>>> breaking changes.
> > > >>>>>>
> > > >> --
> > > >> --
> > > >> François
> > > >>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

That makes lot of sense to me ! We will have:

- ActiveMQ 5.18.x
- ActiveMQ 6.x.x
- ActiveMQ 7.x.x
- ActiveMQ Artemis 2.x
- ActiveMQ Artemis 3.x

So, I propose to have two "spaces" on website:
http://activemq.apache.org/activemq
http://activemq.apache.org/artemis

The index.html will list the two spaces and users will go to one or another.

Thoughts ?

Regards
JB

On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <ro...@gmail.com> wrote:
>
> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
>
> On Tue, 12 Sept 2023 at 13:34, Francois Papon
> <fr...@openobject.fr> wrote:
> >
> > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> >
> > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > That is how I refer to them, or more fully as ActiveMQ 5.x like below,
> > > and ActiveMQ Artemis.
> > >
> > > Same as last time this was discussed, I dont consider "Classic" part
> > > of the actual name, just a reflective description label, quoted for a
> > > reason.
> > >
> > > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> > >> Why not simply ActiveMQ and Artemis?
> > >>
> > >> This is how people used to name the 2 projects, I never eared someone
> > >> say "ActiveMQ Classic".
> > >>
> > >> regards,
> > >>
> > >> François
> > >>
> > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > >>> Same thoughts as last time you proposed it really. Adding Leto would
> > >>> not be an improvement for me, more actually the reverse. I think it's
> > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > >>> confusing. Describing something as 'classic' is a pretty normal /
> > >>> well-known thing, I think a user even noted that on the original
> > >>> thread.
> > >>>
> > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
> > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > >>>>
> > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
> > >>>> Artemis in Greek mythology) to have a clear distinction between the
> > >>>> two subprojects. Thoughts ? :)
> > >>>>
> > >>>> If it's too "sensible", please ignore :)
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>>>
> > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
> > >>>>> makes sense, but please keep a clear distinction - activemq classic 6.0.0
> > >>>>> activemq X may still evolve to combine the best of both.
> > >>>>>
> > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > >>>>> christopher.l.shannon@gmail.com> wrote:
> > >>>>>
> > >>>>>> First, I realize that this thread is likely to cause a fight based on past
> > >>>>>> history and probably not go anywhere, but with the work being done
> > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > >>>>>> ActiveMQ 6.0 discussion.
> > >>>>>>
> > >>>>>> With all the breaking changes currently targeted for version 5.19.x, such
> > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > >>>>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
> > >>>>>> to have this next AMQ version as version 5.19.0 as it's completely
> > >>>>>> incompatible with the previous version 5.18.x. Users are likely going to be
> > >>>>>> in for a rude awakening when trying to upgrade and will be quite confused
> > >>>>>> as to why so much is different.
> > >>>>>>
> > >>>>>> The Jakarta changes should really be a major version upgrade so that it's
> > >>>>>> much more clear to users that it's very different from the previous
> > >>>>>> version. Another major benefit of going with version 6.0 is that it frees
> > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
> > >>>>>> will likely need to support the older javax releases for quite a while.
> > >>>>>>
> > >>>>>> Also, from my point of view it seems pretty clear that the original goal
> > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > >>>>>> its own branding and versioning for several years now and will likely
> > >>>>>> continue that way and not change so I don't really see that as a reason to
> > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >>>>>>
> > >>>>>> Anyways, I figure there won't be much agreement here but thought I should
> > >>>>>> at least throw it out there before we go and release 5.19.x with such major
> > >>>>>> breaking changes.
> > >>>>>>
> > >> --
> > >> --
> > >> François
> > >>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.

On Tue, 12 Sept 2023 at 13:34, Francois Papon
<fr...@openobject.fr> wrote:
>
> So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
>
> On 12/09/2023 14:14, Robbie Gemmell wrote:
> > That is how I refer to them, or more fully as ActiveMQ 5.x like below,
> > and ActiveMQ Artemis.
> >
> > Same as last time this was discussed, I dont consider "Classic" part
> > of the actual name, just a reflective description label, quoted for a
> > reason.
> >
> > On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
> >> Why not simply ActiveMQ and Artemis?
> >>
> >> This is how people used to name the 2 projects, I never eared someone
> >> say "ActiveMQ Classic".
> >>
> >> regards,
> >>
> >> François
> >>
> >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> >>> Same thoughts as last time you proposed it really. Adding Leto would
> >>> not be an improvement for me, more actually the reverse. I think it's
> >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> >>> confusing. Describing something as 'classic' is a pretty normal /
> >>> well-known thing, I think a user even noted that on the original
> >>> thread.
> >>>
> >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
> >>>> most of people uses simply Artemis and ActiveMQ as name)
> >>>>
> >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
> >>>> Artemis in Greek mythology) to have a clear distinction between the
> >>>> two subprojects. Thoughts ? :)
> >>>>
> >>>> If it's too "sensible", please ignore :)
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
> >>>>> makes sense, but please keep a clear distinction - activemq classic 6.0.0
> >>>>> activemq X may still evolve to combine the best of both.
> >>>>>
> >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> >>>>> christopher.l.shannon@gmail.com> wrote:
> >>>>>
> >>>>>> First, I realize that this thread is likely to cause a fight based on past
> >>>>>> history and probably not go anywhere, but with the work being done
> >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> >>>>>> ActiveMQ 6.0 discussion.
> >>>>>>
> >>>>>> With all the breaking changes currently targeted for version 5.19.x, such
> >>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> >>>>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
> >>>>>> to have this next AMQ version as version 5.19.0 as it's completely
> >>>>>> incompatible with the previous version 5.18.x. Users are likely going to be
> >>>>>> in for a rude awakening when trying to upgrade and will be quite confused
> >>>>>> as to why so much is different.
> >>>>>>
> >>>>>> The Jakarta changes should really be a major version upgrade so that it's
> >>>>>> much more clear to users that it's very different from the previous
> >>>>>> version. Another major benefit of going with version 6.0 is that it frees
> >>>>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
> >>>>>> will likely need to support the older javax releases for quite a while.
> >>>>>>
> >>>>>> Also, from my point of view it seems pretty clear that the original goal
> >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> >>>>>> its own branding and versioning for several years now and will likely
> >>>>>> continue that way and not change so I don't really see that as a reason to
> >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> >>>>>>
> >>>>>> Anyways, I figure there won't be much agreement here but thought I should
> >>>>>> at least throw it out there before we go and release 5.19.x with such major
> >>>>>> breaking changes.
> >>>>>>
> >> --
> >> --
> >> François
> >>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Francois Papon <fr...@openobject.fr>]

So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?

On 12/09/2023 14:14, Robbie Gemmell wrote:
> That is how I refer to them, or more fully as ActiveMQ 5.x like below,
> and ActiveMQ Artemis.
>
> Same as last time this was discussed, I dont consider "Classic" part
> of the actual name, just a reflective description label, quoted for a
> reason.
>
> On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
>> Why not simply ActiveMQ and Artemis?
>>
>> This is how people used to name the 2 projects, I never eared someone
>> say "ActiveMQ Classic".
>>
>> regards,
>>
>> François
>>
>> On 12/09/2023 13:07, Robbie Gemmell wrote:
>>> Same thoughts as last time you proposed it really. Adding Leto would
>>> not be an improvement for me, more actually the reverse. I think it's
>>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
>>> confusing. Describing something as 'classic' is a pretty normal /
>>> well-known thing, I think a user even noted that on the original
>>> thread.
>>>
>>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>> Is it a good time to talk about ActiveMQ "Something" instead of
>>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
>>>> most of people uses simply Artemis and ActiveMQ as name)
>>>>
>>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
>>>> Artemis in Greek mythology) to have a clear distinction between the
>>>> two subprojects. Thoughts ? :)
>>>>
>>>> If it's too "sensible", please ignore :)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
>>>>> makes sense, but please keep a clear distinction - activemq classic 6.0.0
>>>>> activemq X may still evolve to combine the best of both.
>>>>>
>>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
>>>>> christopher.l.shannon@gmail.com> wrote:
>>>>>
>>>>>> First, I realize that this thread is likely to cause a fight based on past
>>>>>> history and probably not go anywhere, but with the work being done
>>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
>>>>>> ActiveMQ 6.0 discussion.
>>>>>>
>>>>>> With all the breaking changes currently targeted for version 5.19.x, such
>>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
>>>>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
>>>>>> to have this next AMQ version as version 5.19.0 as it's completely
>>>>>> incompatible with the previous version 5.18.x. Users are likely going to be
>>>>>> in for a rude awakening when trying to upgrade and will be quite confused
>>>>>> as to why so much is different.
>>>>>>
>>>>>> The Jakarta changes should really be a major version upgrade so that it's
>>>>>> much more clear to users that it's very different from the previous
>>>>>> version. Another major benefit of going with version 6.0 is that it frees
>>>>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
>>>>>> will likely need to support the older javax releases for quite a while.
>>>>>>
>>>>>> Also, from my point of view it seems pretty clear that the original goal
>>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
>>>>>> its own branding and versioning for several years now and will likely
>>>>>> continue that way and not change so I don't really see that as a reason to
>>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
>>>>>>
>>>>>> Anyways, I figure there won't be much agreement here but thought I should
>>>>>> at least throw it out there before we go and release 5.19.x with such major
>>>>>> breaking changes.
>>>>>>
>> --
>> --
>> François
>>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

That is how I refer to them, or more fully as ActiveMQ 5.x like below,
and ActiveMQ Artemis.

Same as last time this was discussed, I dont consider "Classic" part
of the actual name, just a reflective description label, quoted for a
reason.

On Tue, 12 Sept 2023 at 12:48, fpapon <fp...@apache.org> wrote:
>
> Why not simply ActiveMQ and Artemis?
>
> This is how people used to name the 2 projects, I never eared someone
> say "ActiveMQ Classic".
>
> regards,
>
> François
>
> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > Same thoughts as last time you proposed it really. Adding Leto would
> > not be an improvement for me, more actually the reverse. I think it's
> > fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > confusing. Describing something as 'classic' is a pretty normal /
> > well-known thing, I think a user even noted that on the original
> > thread.
> >
> > On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >> Is it a good time to talk about ActiveMQ "Something" instead of
> >> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
> >> most of people uses simply Artemis and ActiveMQ as name)
> >>
> >> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
> >> Artemis in Greek mythology) to have a clear distinction between the
> >> two subprojects. Thoughts ? :)
> >>
> >> If it's too "sensible", please ignore :)
> >>
> >> Regards
> >> JB
> >>
> >> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
> >>> makes sense, but please keep a clear distinction - activemq classic 6.0.0
> >>> activemq X may still evolve to combine the best of both.
> >>>
> >>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> >>> christopher.l.shannon@gmail.com> wrote:
> >>>
> >>>> First, I realize that this thread is likely to cause a fight based on past
> >>>> history and probably not go anywhere, but with the work being done
> >>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> >>>> ActiveMQ 6.0 discussion.
> >>>>
> >>>> With all the breaking changes currently targeted for version 5.19.x, such
> >>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> >>>> upgrades and now potentially major OSGi changes, it makes zero sense to me
> >>>> to have this next AMQ version as version 5.19.0 as it's completely
> >>>> incompatible with the previous version 5.18.x. Users are likely going to be
> >>>> in for a rude awakening when trying to upgrade and will be quite confused
> >>>> as to why so much is different.
> >>>>
> >>>> The Jakarta changes should really be a major version upgrade so that it's
> >>>> much more clear to users that it's very different from the previous
> >>>> version. Another major benefit of going with version 6.0 is that it frees
> >>>> up the previous javax releases to continue on with 5.19 or 5.20 because we
> >>>> will likely need to support the older javax releases for quite a while.
> >>>>
> >>>> Also, from my point of view it seems pretty clear that the original goal
> >>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> >>>> its own branding and versioning for several years now and will likely
> >>>> continue that way and not change so I don't really see that as a reason to
> >>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> >>>>
> >>>> Anyways, I figure there won't be much agreement here but thought I should
> >>>> at least throw it out there before we go and release 5.19.x with such major
> >>>> breaking changes.
> >>>>
> --
> --
> François
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

Same thoughts as last time you proposed it really. Adding Leto would
not be an improvement for me, more actually the reverse. I think it's
fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
confusing. Describing something as 'classic' is a pretty normal /
well-known thing, I think a user even noted that on the original
thread.

On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Is it a good time to talk about ActiveMQ "Something" instead of
> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
> most of people uses simply Artemis and ActiveMQ as name)
>
> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
> Artemis in Greek mythology) to have a clear distinction between the
> two subprojects. Thoughts ? :)
>
> If it's too "sensible", please ignore :)
>
> Regards
> JB
>
> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
> >
> > makes sense, but please keep a clear distinction - activemq classic 6.0.0
> > activemq X may still evolve to combine the best of both.
> >
> > On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > First, I realize that this thread is likely to cause a fight based on past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x, such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going to be
> > > in for a rude awakening when trying to upgrade and will be quite confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it frees
> > > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a reason to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I should
> > > at least throw it out there before we go and release 5.19.x with such major
> > > breaking changes.
> > >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Is it a good time to talk about ActiveMQ "Something" instead of
"Classic" ? (I hate this "classic" naming (it sounds weird to me) and
most of people uses simply Artemis and ActiveMQ as name)

I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
Artemis in Greek mythology) to have a clear distinction between the
two subprojects. Thoughts ? :)

If it's too "sensible", please ignore :)

Regards
JB

On Tue, Sep 12, 2023 at 11:11 AM Gary Tully <gt...@apache.org> wrote:
>
> makes sense, but please keep a clear distinction - activemq classic 6.0.0
> activemq X may still evolve to combine the best of both.
>
> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > First, I realize that this thread is likely to cause a fight based on past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such major
> > breaking changes.
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Gary Tully <gt...@apache.org>]

makes sense, but please keep a clear distinction - activemq classic 6.0.0
activemq X may still evolve to combine the best of both.

On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Arthur Naseef <ar...@amlinv.com>]

I agree.  We have had breaking changes in the 5.x series, and that's bad.
We may not be perfect in maintaining semantic versioning, but it is
important.

The Jakarta changes are definitely a major concern if we stick to 5.x.

Is there any reason to avoid using 6.x?  I looked around to see if we ever
had any artifacts released with that version number and didn't find any...

Art


On Mon, Sep 11, 2023 at 3:05 PM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> Jeff,
>
> That's a good point about Artemis possibly being 7.0, that's fine too.
>
> This is nothing against Artemis, really it's just this release completely
> breaks everything and is not compatible at all so I really think it would
> be terrible to release it as 5.19.x as for the last 10+ years people have
> expected to mostly just upgrade from one 5.x version to the next without
> much issue.
>
> Chris
>
> On Mon, Sep 11, 2023 at 5:31 PM fpapon <fp...@apache.org> wrote:
>
> > Hi,
> >
> > Make totally sense, especially about keeping the javax version
> > supported, so need to split in 2 major versions.
> >
> > Big +1
> >
> > regards,
> >
> > François
> >
> > On 11/09/2023 23:14, Christopher Shannon wrote:
> > > First, I realize that this thread is likely to cause a fight based on
> > past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x,
> such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and
> > Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense to
> > me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going
> to
> > be
> > > in for a rude awakening when trying to upgrade and will be quite
> confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that
> it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it
> frees
> > > up the previous javax releases to continue on with 5.19 or 5.20 because
> > we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original
> goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has
> > had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a reason
> > to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I
> should
> > > at least throw it out there before we go and release 5.19.x with such
> > major
> > > breaking changes.
> > >
> > --
> > --
> > François
> >
> >
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Christopher Shannon <ch...@gmail.com>]

Jeff,

That's a good point about Artemis possibly being 7.0, that's fine too.

This is nothing against Artemis, really it's just this release completely
breaks everything and is not compatible at all so I really think it would
be terrible to release it as 5.19.x as for the last 10+ years people have
expected to mostly just upgrade from one 5.x version to the next without
much issue.

Chris

On Mon, Sep 11, 2023 at 5:31 PM fpapon <fp...@apache.org> wrote:

> Hi,
>
> Make totally sense, especially about keeping the javax version
> supported, so need to split in 2 major versions.
>
> Big +1
>
> regards,
>
> François
>
> On 11/09/2023 23:14, Christopher Shannon wrote:
> > First, I realize that this thread is likely to cause a fight based on
> past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and
> Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to
> me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to
> be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because
> we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has
> had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason
> to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such
> major
> > breaking changes.
> >
> --
> --
> François
>
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[fpapon <fp...@apache.org>]

Hi,

Make totally sense, especially about keeping the javax version 
supported, so need to split in 2 major versions.

Big +1

regards,

François

On 11/09/2023 23:14, Christopher Shannon wrote:
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.
>
-- 
--
François

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell <ro...@gmail.com>]

Seems sensible to me.

On Mon, 11 Sept 2023 at 22:15, Christopher Shannon
<ch...@gmail.com> wrote:
>
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.