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é <j...@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.gemm...@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 > > <francois.pa...@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 <fpa...@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é < > j...@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 <gtu...@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.shan...@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 > > > >> > >