activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: About ActiveMQ 5.3 and issues management
Date Thu, 16 Jul 2009 14:30:52 GMT
There is no schedule as such, save that I think we should wait till
camel 2.0 is released and the outstanding (13) scheduled issues from
are resolved along with anything critical that pops up in the mean
time. It is very hard to put an exact time line on this, in addition,
the testing that follow a release candidate can often precipitate new

The push out of issues to 5.3.4 was the first effort to constrain the
release. I tried to retain any issue that had a patch and junit test.
Part of the intention was to solicit response, so in your case, it
looks like AMQ-2216 should be reinstated as fix for 5.3.

We welcome, appreciate and want to encourage your contribution so
apologies if it looked like it was being ignored.

2009/7/16 ffrenchm <>:
> Hello,
> I noticed that many issue from ActiveMQ 5.3 has been moved to ActiveMQ 5.4
> and unscheduled. So I've the impression that ActiveMQ 5.3 will be delivered
> soon. Am I false ? Where can I find the schedule of ActiveMQ 5.3 delivery ?
> I noticed that for ActiveMQ 5.2 the delivery is based on a svn TAG. That's
> mean no patch or SP delivery on this version. Will you apply the same policy
> for ActiveMQ 5.3 ?
> Finally I noticed that the issues I raised like many others has been moved
> to 'unscheduled'. My problem is that for one of these issues (AMQ-2216) I
> provided a correction with JUNIT test and I'm currently using ActiveMQ 5.3
> with this correction. The aim of my work is to make work ActiveMQ at
> production.
> So I would like to get a feed back from ActiveMQ experts on this correction
> and I would like to know your point on how I'm supposed to deliver ActiveMQ
> if this correction is not scheduled on any ActiveMQ delivery ? From my point
> it seems I need to work independently on ActiveMQ source code and finally
> deliver a forked ActiveMQ which finally means:
> + a dubious correction report from ActiveMQ trunk on my side.
> + a fall of my motivation to provide correction and JUNIT test in order to
> help ActiveMQ community as it's not enough to get a quicker resolution on my
> issue.
> + finally a fall of potential commiters on ActiveMQ side (in this case me
> because 'never say never' :).
> I don't like this solution because I prefer to work with the ActiveMQ
> community as much as possible. But as I've also delivery deadline I must
> choose the most proper way to achieve my aim and today it's seems for me the
> most proper way is to fork ActiveMQ on my side and work independently on
> this fork.
> Thanks for your answers
> --
> View this message in context:
> Sent from the ActiveMQ - Dev mailing list archive at


Open Source Integration

View raw message