I agree with Justin, I would include any new features or only add any API changes into 6.2.0.
I would keep any 6.1.x releases to only bug fixes. We can always do quicker releases, there is no reason we can't do a 6.2.0 and then a 6.3.0 and a 6.4.0 quickly but it keeps the semantics cleaner so users know what to expect. On Thu, Oct 31, 2024 at 11:21 AM Justin Bertram <jbert...@apache.org> wrote: > Wouldn't new functionality like this make more sense in a minor release > (i.e. 6.2.0) rather than a micro release (i.e. 6.1.4)? Micro releases are > typically for bug fixes and maybe some trivial improvements. I believe Matt > made this same point when discussing 6.1.4 last month [1]. > > > Justin > > [1] https://lists.apache.org/thread/spj8fm567367qy0w3q98oombss64ok6q > > On Thu, Oct 31, 2024 at 10:10 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi folks, > > > > I'm starting the preparation of the ActiveMQ Classic 6.1.4 release. > > > > In addition to the improvements and bug fixes, I propose to move > > forward on the full JMS 2/Jakarta 3 support. > > > > I propose to include two additional JMS2 features in 6.1.4: > > - support of JMSConsumer.readBody(Class) > > (https://issues.apache.org/jira/browse/AMQ-8464). I'm resuming work on > > this one. > > - support for JMSProducer deliveryDelay > > (https://issues.apache.org/jira/browse/AMQ-8320). Matt is working on > > it. > > > > We will be able to focus on producer CompletionListener (AMQ-8324) and > > Shared Topic Consumers (AMQ-8323) features in 6.1.5, 6.1.6, 6.1.7. > > > > I think it makes sense to take the time to complete AMQ-8464 and > > AMQ-8320 for 6.1.4. > > > > Thoughts ? > > > > Regards > > JB > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > For additional commands, e-mail: dev-h...@activemq.apache.org > > For further information, visit: https://activemq.apache.org/contact > > > > > > >
