Hi
I think 1.1.0 is better.
Maybe here in the start where more new functions is added / ported
from AMQ 5.x then the upcoming releases are IMHO more fitted as new
minor releases, than patch releases.
And then when Artemis has a great set of features in 1.x, then
dedicated patch releases could
+1
I tested AMQ 5.12.0 with the master branch of Apache Camel
On Mon, Aug 10, 2015 at 8:11 PM, Timothy Bish tabish...@gmail.com wrote:
Hi folks,
I've just cut a release candidate for the ActiveMQ 5.12.0 release and
it's ready for a vote. This release has 180+ bug fixes and
improvements. A
+1
On Wed, Aug 12, 2015 at 4:44 PM, Timothy Bish tabish...@gmail.com wrote:
New vote open for ActiveMQ-CPP v3.9.0 with fixed archives.
This is a new major release of the ActiveMQ-CPP client. I've ported
most of the applicable fixes from the JMS client over to the C++ client
as well as added
Yeah I think 1.1.0 fits better too, both for whats actually in it now
and also for a future approach like Claus mentioned.
Robbie
On 13 August 2015 at 08:53, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
I think 1.1.0 is better.
Maybe here in the start where more new functions is added /
Just to add, I think from 1.1 we do it the way suggested i.e minor
versions for patch releases etc but until Artemis can be regarded as a
possible alternative to activemq I think stick to 1.0.1, having lots of
major versions will just confuse people imo
On Thu, 13 Aug 2015 18:03 Andy Taylor
I have to disagree. We haven't really done a real major release. This first
one was for ip clearance and we will be adding new functionality in every
release and we don't want to end up at 1.20 before we know it. To me 1.1
will be the first release where we have some sort of feature parity with
A new Jira was put in today: https://issues.apache.org/jira/browse/AMQ-5926
Camel is not being included in the activemq-all shaded jar (but it looks
like all of the other dependencies are). I was wondering if this was done
intentionally or not and whether we should change it.
On Thu, Aug 13, 2015 at 1:44 PM, Andy Taylor andy.tayl...@gmail.com wrote:
Just to add, I think from 1.1 we do it the way suggested i.e minor
versions for patch releases etc but until Artemis can be regarded as a
possible alternative to activemq I think stick to 1.0.1, having lots of
major
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/126
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
My recommendation is to use semantic versioning and stick with it:
* x.y.z
* z = bug fixes only
* y = any new features or changes to existing features
* x = any backward compatibility loss in APIs / usage of the product
With that said, whatever approach is used, let's make clear guidelines and
GitHub user clebertsuconic opened a pull request:
https://github.com/apache/activemq-artemis/pull/126
Openwire fixes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/clebertsuconic/activemq-artemis openwire
Alternatively you can
Is it not possible to use a broker discovery method for this purpose? It
should be simple enough to implement the DiscoveryAgent interface and plug
it into the brokers. Take a look at DiscoveryNetworkConnector for that
approach.
To directly add network connectors to a running broker, use one of
Say you put this as 1.0.1. A month from now there is a bug fix and an user
don't want all the updates from 1.0.2 on his production env. What would call
it? 1.0.1.1?
These releases are production ready and not beta.
We can promote it to 2.0.0 when we decide we have a whole completion of
. To be honest I
guess it doesn't matter if it's 1
0.1 or 1.1 but to me 1.1 implies a milestone of some sort has been reached.
The current branch has Mqtt and lots of improvements compared to 1.0.0. It's
not just a minor update.
So it is a milestone to me.
Anyways. Users are more likely
GitHub user clebertsuconic opened a pull request:
https://github.com/apache/activemq-artemis/pull/127
ARTEMIS-187 hold lock between live server and tools
This should avoid users damaging data while the server is running (by for
instance running compact while the server is running)
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/127
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
16 matches
Mail list logo
