You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Matt Pavlovich <ma...@gmail.com> on 2024/02/27 19:16:15 UTC
Re: [PROPOSAL] ActiveMQ 6.0.x/6.1.x/... roadmap
Hi JB-
Thanks for kicking off the convo, I think we are mostly in agreement.
We have more headroom with versions, so I think it would be good to be closer to SEMVER going forward.
6.0.x - Dependency updates (non-major changes). ActiveMQ bug and security fixes only. No new config flags (unless as part of a fix) or new features.
6.1.x - New features, new config flags, new JMS 2.x features, etc
I think 6.5.x is probably reasonable for full JMS 2.0 compliance. Chris started on the openwire modernization work, and I’ve got a couple tasks to kick-in over there as well.
Main changes for openwire — deliveryDelay field and shared subscription flag.
I have a PR for Virtual Thread support and plan on updating it to make it something that can be releasable without having to move everyone to JDK 21 in 6.x. Getting some runtime testing with Virtual Threads in 6.x will be good and give data to consider it for the default in 7.x/8.x.
Regarding 7.x — I think we can move more towards ‘services’ and DestinationPolicy add-ons vs ‘plugins'. I plan to start implementing more features under destination policy to replace more plugins (timestamp, forced persistence mode, etc). A config service that re-uses a lot from runtime config plugin would provide a lot of transition support towards an activemq-boot mini-kernel to replace Spring/XBean.
Thanks,
Matt Pavlovich
> On Jan 12, 2024, at 12:22 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi guys,
>
> Happy new year to all !
>
> After the festive break, I'm back on ActiveMQ :)
> I would like to discuss about the roadmap for ActiveMQ
> 6.0.x/6.1.x/6.2.x/7.x(future):
>
> - For 6.0.x branch, I propose to include fixes and minor dependencies
> updates (I have some PRs on the way, Matt also worked on different
> topics)
> - For 6.1.x branch, I propose to add a new round of JMS 2.x/3.x
> features support and include major dependencies updates (if there are
> :)). It can also include non breaking change refactoring.
> - For 6.2.x branch, I propose to add another round of JMS 2.x/3.x
> features support and new major updates compared to 6.1.x
> It would be great to target 6.5.x for instance for full JMS 2.x/3.x support.
>
> - For 7.x, I started a prototype to set Spring as optional, having a
> core loader and new configuration format (in addition to activemq.xml,
> I have activemq.json and activemq.yml for instance). As this is a
> major milestone, we could have some breaking changes. Even if 7.x is
> not the top priority for now (I think we have to focus on full JMS 2/3
> support right now), it gives perspective to the community.
>
> Thoughts ?
>
> Regards
> JB
Re: [PROPOSAL] ActiveMQ 6.0.x/6.1.x/... roadmap
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yeah, you are right: it's better to not take any commitment for a
specific version.
Let's do our best to add the missing parts, and we will do the
releases on the fly.
Regards
JB
On Thu, Feb 29, 2024 at 1:31 PM Christopher Shannon
<ch...@gmail.com> wrote:
>
> Everything seems fine as a general guideline but I wouldn't guarantee "full
> compliance" on any specific 6.x release as it's just hard to say when it
> will happen. It's a goal that is being worked on each release and there's
> still a good amount of work to do so hopefully we get there but it's hard
> to say if it will be 6.5 or 6.6 etc. Certainly if/when a 7.0 release
> happens I would expect that to be fully Jakarta compliant with the spec.
>
> On Thu, Feb 29, 2024 at 2:02 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi Matt
> >
> > Yeah, agree. It sounds good.
> >
> > I'm on the releases right now. Votes will come soon :)
> >
> > Regards
> > JB
> >
> > On Tue, Feb 27, 2024 at 8:16 PM Matt Pavlovich <ma...@gmail.com> wrote:
> > >
> > > Hi JB-
> > >
> > > Thanks for kicking off the convo, I think we are mostly in agreement.
> > >
> > > We have more headroom with versions, so I think it would be good to be
> > closer to SEMVER going forward.
> > >
> > > 6.0.x - Dependency updates (non-major changes). ActiveMQ bug and
> > security fixes only. No new config flags (unless as part of a fix) or new
> > features.
> > >
> > > 6.1.x - New features, new config flags, new JMS 2.x features, etc
> > >
> > > I think 6.5.x is probably reasonable for full JMS 2.0 compliance. Chris
> > started on the openwire modernization work, and I’ve got a couple tasks to
> > kick-in over there as well.
> > >
> > > Main changes for openwire — deliveryDelay field and shared subscription
> > flag.
> > >
> > > I have a PR for Virtual Thread support and plan on updating it to make
> > it something that can be releasable without having to move everyone to JDK
> > 21 in 6.x. Getting some runtime testing with Virtual Threads in 6.x will be
> > good and give data to consider it for the default in 7.x/8.x.
> > >
> > > Regarding 7.x — I think we can move more towards ‘services’ and
> > DestinationPolicy add-ons vs ‘plugins'. I plan to start implementing more
> > features under destination policy to replace more plugins (timestamp,
> > forced persistence mode, etc). A config service that re-uses a lot from
> > runtime config plugin would provide a lot of transition support towards an
> > activemq-boot mini-kernel to replace Spring/XBean.
> > >
> > > Thanks,
> > > Matt Pavlovich
> > >
> > > > On Jan 12, 2024, at 12:22 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> > > >
> > > > Hi guys,
> > > >
> > > > Happy new year to all !
> > > >
> > > > After the festive break, I'm back on ActiveMQ :)
> > > > I would like to discuss about the roadmap for ActiveMQ
> > > > 6.0.x/6.1.x/6.2.x/7.x(future):
> > > >
> > > > - For 6.0.x branch, I propose to include fixes and minor dependencies
> > > > updates (I have some PRs on the way, Matt also worked on different
> > > > topics)
> > > > - For 6.1.x branch, I propose to add a new round of JMS 2.x/3.x
> > > > features support and include major dependencies updates (if there are
> > > > :)). It can also include non breaking change refactoring.
> > > > - For 6.2.x branch, I propose to add another round of JMS 2.x/3.x
> > > > features support and new major updates compared to 6.1.x
> > > > It would be great to target 6.5.x for instance for full JMS 2.x/3.x
> > support.
> > > >
> > > > - For 7.x, I started a prototype to set Spring as optional, having a
> > > > core loader and new configuration format (in addition to activemq.xml,
> > > > I have activemq.json and activemq.yml for instance). As this is a
> > > > major milestone, we could have some breaking changes. Even if 7.x is
> > > > not the top priority for now (I think we have to focus on full JMS 2/3
> > > > support right now), it gives perspective to the community.
> > > >
> > > > Thoughts ?
> > > >
> > > > Regards
> > > > JB
> > >
> >
Re: [PROPOSAL] ActiveMQ 6.0.x/6.1.x/... roadmap
Posted by Christopher Shannon <ch...@gmail.com>.
Everything seems fine as a general guideline but I wouldn't guarantee "full
compliance" on any specific 6.x release as it's just hard to say when it
will happen. It's a goal that is being worked on each release and there's
still a good amount of work to do so hopefully we get there but it's hard
to say if it will be 6.5 or 6.6 etc. Certainly if/when a 7.0 release
happens I would expect that to be fully Jakarta compliant with the spec.
On Thu, Feb 29, 2024 at 2:02 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Matt
>
> Yeah, agree. It sounds good.
>
> I'm on the releases right now. Votes will come soon :)
>
> Regards
> JB
>
> On Tue, Feb 27, 2024 at 8:16 PM Matt Pavlovich <ma...@gmail.com> wrote:
> >
> > Hi JB-
> >
> > Thanks for kicking off the convo, I think we are mostly in agreement.
> >
> > We have more headroom with versions, so I think it would be good to be
> closer to SEMVER going forward.
> >
> > 6.0.x - Dependency updates (non-major changes). ActiveMQ bug and
> security fixes only. No new config flags (unless as part of a fix) or new
> features.
> >
> > 6.1.x - New features, new config flags, new JMS 2.x features, etc
> >
> > I think 6.5.x is probably reasonable for full JMS 2.0 compliance. Chris
> started on the openwire modernization work, and I’ve got a couple tasks to
> kick-in over there as well.
> >
> > Main changes for openwire — deliveryDelay field and shared subscription
> flag.
> >
> > I have a PR for Virtual Thread support and plan on updating it to make
> it something that can be releasable without having to move everyone to JDK
> 21 in 6.x. Getting some runtime testing with Virtual Threads in 6.x will be
> good and give data to consider it for the default in 7.x/8.x.
> >
> > Regarding 7.x — I think we can move more towards ‘services’ and
> DestinationPolicy add-ons vs ‘plugins'. I plan to start implementing more
> features under destination policy to replace more plugins (timestamp,
> forced persistence mode, etc). A config service that re-uses a lot from
> runtime config plugin would provide a lot of transition support towards an
> activemq-boot mini-kernel to replace Spring/XBean.
> >
> > Thanks,
> > Matt Pavlovich
> >
> > > On Jan 12, 2024, at 12:22 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> > >
> > > Hi guys,
> > >
> > > Happy new year to all !
> > >
> > > After the festive break, I'm back on ActiveMQ :)
> > > I would like to discuss about the roadmap for ActiveMQ
> > > 6.0.x/6.1.x/6.2.x/7.x(future):
> > >
> > > - For 6.0.x branch, I propose to include fixes and minor dependencies
> > > updates (I have some PRs on the way, Matt also worked on different
> > > topics)
> > > - For 6.1.x branch, I propose to add a new round of JMS 2.x/3.x
> > > features support and include major dependencies updates (if there are
> > > :)). It can also include non breaking change refactoring.
> > > - For 6.2.x branch, I propose to add another round of JMS 2.x/3.x
> > > features support and new major updates compared to 6.1.x
> > > It would be great to target 6.5.x for instance for full JMS 2.x/3.x
> support.
> > >
> > > - For 7.x, I started a prototype to set Spring as optional, having a
> > > core loader and new configuration format (in addition to activemq.xml,
> > > I have activemq.json and activemq.yml for instance). As this is a
> > > major milestone, we could have some breaking changes. Even if 7.x is
> > > not the top priority for now (I think we have to focus on full JMS 2/3
> > > support right now), it gives perspective to the community.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> >
>
Re: [PROPOSAL] ActiveMQ 6.0.x/6.1.x/... roadmap
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Matt
Yeah, agree. It sounds good.
I'm on the releases right now. Votes will come soon :)
Regards
JB
On Tue, Feb 27, 2024 at 8:16 PM Matt Pavlovich <ma...@gmail.com> wrote:
>
> Hi JB-
>
> Thanks for kicking off the convo, I think we are mostly in agreement.
>
> We have more headroom with versions, so I think it would be good to be closer to SEMVER going forward.
>
> 6.0.x - Dependency updates (non-major changes). ActiveMQ bug and security fixes only. No new config flags (unless as part of a fix) or new features.
>
> 6.1.x - New features, new config flags, new JMS 2.x features, etc
>
> I think 6.5.x is probably reasonable for full JMS 2.0 compliance. Chris started on the openwire modernization work, and I’ve got a couple tasks to kick-in over there as well.
>
> Main changes for openwire — deliveryDelay field and shared subscription flag.
>
> I have a PR for Virtual Thread support and plan on updating it to make it something that can be releasable without having to move everyone to JDK 21 in 6.x. Getting some runtime testing with Virtual Threads in 6.x will be good and give data to consider it for the default in 7.x/8.x.
>
> Regarding 7.x — I think we can move more towards ‘services’ and DestinationPolicy add-ons vs ‘plugins'. I plan to start implementing more features under destination policy to replace more plugins (timestamp, forced persistence mode, etc). A config service that re-uses a lot from runtime config plugin would provide a lot of transition support towards an activemq-boot mini-kernel to replace Spring/XBean.
>
> Thanks,
> Matt Pavlovich
>
> > On Jan 12, 2024, at 12:22 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >
> > Hi guys,
> >
> > Happy new year to all !
> >
> > After the festive break, I'm back on ActiveMQ :)
> > I would like to discuss about the roadmap for ActiveMQ
> > 6.0.x/6.1.x/6.2.x/7.x(future):
> >
> > - For 6.0.x branch, I propose to include fixes and minor dependencies
> > updates (I have some PRs on the way, Matt also worked on different
> > topics)
> > - For 6.1.x branch, I propose to add a new round of JMS 2.x/3.x
> > features support and include major dependencies updates (if there are
> > :)). It can also include non breaking change refactoring.
> > - For 6.2.x branch, I propose to add another round of JMS 2.x/3.x
> > features support and new major updates compared to 6.1.x
> > It would be great to target 6.5.x for instance for full JMS 2.x/3.x support.
> >
> > - For 7.x, I started a prototype to set Spring as optional, having a
> > core loader and new configuration format (in addition to activemq.xml,
> > I have activemq.json and activemq.yml for instance). As this is a
> > major milestone, we could have some breaking changes. Even if 7.x is
> > not the top priority for now (I think we have to focus on full JMS 2/3
> > support right now), it gives perspective to the community.
> >
> > Thoughts ?
> >
> > Regards
> > JB
>