On Thu, Dec 8, 2016 at 4:44 PM, Martyn Taylor wrote:
>
>
> On Thu, Dec 8, 2016 at 4:35 PM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
>> I was not implying that the feature parity with ActiveMQ is a marketing
>> goal. I just wanted to show a case where typically in companies market
On 12/8/16 11:35 AM, Christian Schneider wrote:
I was not implying that the feature parity with ActiveMQ is a
marketing goal. I just wanted to show a case where typically in
companies marketing pushes for a major release based on a feature set
as they think they can sell it better. As an open
On Thu, Dec 8, 2016 at 4:35 PM, Christian Schneider wrote:
> I was not implying that the feature parity with ActiveMQ is a marketing
> goal. I just wanted to show a case where typically in companies marketing
> pushes for a major release based on a feature set as they think they can
> sell it bet
I was not implying that the feature parity with ActiveMQ is a marketing
goal. I just wanted to show a case where typically in companies
marketing pushes for a major release based on a feature set as they
think they can sell it better. As an open source project
ActiveMQ/Artemis has the luxury to
Gotcha.. that sounds good. Thanks.
On 12/8/16 11:05 AM, Andy Taylor wrote:
I think Christian's issue is not with feature parity being a marketing goal
but the fact that you aligned a major bump with a feature set rather than
API changes etc.
we have had this conversation a couple of times and a
I think Christian's issue is not with feature parity being a marketing goal
but the fact that you aligned a major bump with a feature set rather than
API changes etc.
we have had this conversation a couple of times and altho its a good idea
the discussion just goes of on all tangents since everyon
Christian-
Are there any features or API breaking changes you'd like to see? My #1
goal is to kick off a conversation.
I don't think setting goals like "feature parity w/ ActiveMQ 5.x" is a
marketing goal. I think it is a user-centric goal. Users use features.
For Artemis to be a suitable up
I think trying to address everything on your list in a single release is
probably a little ambitious. However, a major goal for Artemis is to try
to fill many of those feature gaps as possible (or at least offer similar
features that address the same use cases). It'd be great if your notes
were c
I agree a major bump should only be required when breakages appear in APIs
or incompatability of existing client applications. That doesn't mean we
can't have a discussion about what features people would like in upcoming
releases.
On Thu, Dec 8, 2016 at 7:33 AM, Jean-Baptiste Onofré
wrote:
> A
Agree with Christian. It's a bit unfortunate.
Regards
JB
On Dec 8, 2016, 07:53, at 07:53, Christian Schneider
wrote:
>As artemis is an open source project I would not use a marketing like
>reason for a new major version (like a certain feature set).
>Instead I would use a major version to rem
As artemis is an open source project I would not use a marketing like
reason for a new major version (like a certain feature set).
Instead I would use a major version to remove deprecated interfaces. So
basically to remove stuff in a way that might be incompatible to older
clients.
For pure feature
On 12/07/2016 04:29 PM, Matt Pavlovich wrote:
*** Re-sending w/ [DISCUSS] subject tag
Kicking off a discussion on what folks would like to see in 2.0.0
release for Artemis. My thought is that we should target ActiveMQ 5.x
feature parity in an effort to solidify Artemis in the product sense.
I
*** Re-sending w/ [DISCUSS] subject tag
Kicking off a discussion on what folks would like to see in 2.0.0
release for Artemis. My thought is that we should target ActiveMQ 5.x
feature parity in an effort to solidify Artemis in the product sense. I
will detail out specifics from my previous not
13 matches
Mail list logo
