Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 92F0017491 for ; Tue, 24 Feb 2015 15:26:19 +0000 (UTC) Received: (qmail 31347 invoked by uid 500); 24 Feb 2015 15:26:11 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 31309 invoked by uid 500); 24 Feb 2015 15:26:11 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 31297 invoked by uid 99); 24 Feb 2015 15:26:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2015 15:26:11 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rob.j.godfrey@gmail.com designates 209.85.216.46 as permitted sender) Received: from [209.85.216.46] (HELO mail-qa0-f46.google.com) (209.85.216.46) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2015 15:26:05 +0000 Received: by mail-qa0-f46.google.com with SMTP id n4so27618749qaq.5 for ; Tue, 24 Feb 2015 07:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fRu4KFEjm0rWbQZ4/8hnTD7ygD1O3AdX2qCjaC6h8ho=; b=w2YDZfjtyS+gtMPW1X9z5V4QgQ5bI/O4YNldKW3o6o4EDwkNaHyPO9WA4Bhx1zQqbH 2N2uSL8QZiG0ySL5MvAuViKE65+0mOI75f0iURK4SXExlswvkk7qb6dh260+Hr/cfSIj o4cj6pDXYLncgRHtwb9A6EDlE9iv4UMQ/YJWaVdI36w8dUa6Y40oIyAw1YLnFrWMDOzC dZbKnDj9PpUdgHdMqRu94WH9CG5FSwUAHoLs4vWAODkal9bMm1VurdUESn+1iqO9Rtsi LvLi9y3/yhy8mwjWIVg24ukUX2BvXLdU7r+EVzaleEQrwgSfWDBsE8OZleH2A+qT/FXm HrjA== MIME-Version: 1.0 X-Received: by 10.140.150.146 with SMTP id 140mr10468673qhw.66.1424791500019; Tue, 24 Feb 2015 07:25:00 -0800 (PST) Received: by 10.140.94.238 with HTTP; Tue, 24 Feb 2015 07:24:59 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 16:24:59 +0100 Message-ID: Subject: Re: towards releasing the new AMQP 1.0 JMS client From: Rob Godfrey To: "users@qpid.apache.org" Content-Type: multipart/alternative; boundary=001a113575b83ce07c050fd71f15 X-Virus-Checked: Checked by ClamAV on apache.org --001a113575b83ce07c050fd71f15 Content-Type: text/plain; charset=UTF-8 So, I'm very much in favour of getting the new client released as soon as possible. In terms of the old "JMS AMQP 1.0 Client" I suggest that post 0.32 we put this into maintenance mode only... and that as we move to our new release/directory structure we remove the legacy AMQP 1.0 client and only release maintenance updates based on the 0.32 branch (as 0.32.1, 0.32.2 etc). Does anyone object to this plan? -- Rob On 18 February 2015 at 13:33, Robbie Gemmell wrote: > Hi all, > > We are getting to the point of wanting to do an initial release of the > new AMQP 1.0 JMS client, which raises some items for discussion. > > The quick summary of an email that got quite long is: How do we > version it? What do we name it? How do we handle the overlap with the > older AMQP 1.0 JMS client? > > > We have yet to begin publishing snapshots but this is something I > would like to do soon, once we have a better idea around some of these > items, so that people can test with it more easily before/between > releases. > > At the moment the version number is 0.1[-SNAPSHOT], to be followed by > 0.2 etc until we think there is sufficient maturity to go 1.0 > (sidenote: not years :P). The initial focus has been on implementing > the JMS 1.1 API for now so change will come once we begin implementing > the JMS 2.0 API, which could also be when we bump to 2.0 for the > client itself if we hadn't already for other reasons. I envisage us > doing releases more frequently than our existing components have > tended to and expect we will do small point releases eventually, so I > think it probably makes sense to use 0.1.0 etc from the start (or even > 0.0.1 to underscore its the initial release). We could consider adding > alpha/beta etc status, however we would then have to contend with the > version ordering disparities between e.g Maven and OSGi by crafting > some horrible release versions (including the final versions), and I'm > not much of a fan of publishing those to central. > > Next up is the name. The new client has thus far been called simply > 'Qpid JMS', with module names qpid-jms-foo, and binary tar > apache-qpid-jms[-bin]. We already release two other JMS clients, the > original AMQP 0-x one, module named qpid-client, and the older AMQP > 1.0 one, module named qpid-amqp-1-0-jms-client. Although the new > clients name describes what it is, and the version numbers will differ > from the previous clients, do people think this is enough difference? > I think it is still going to be confusing for people no matter what we > do here, but should we perhaps give the new client a component name to > allow them more easily distinguished, i.e a name of the style Qpid Foo > or Qpid FooJMS? If so, any ideas (failing spectacularly over here)? > > As mentioned, we already release the older AMQP 1.0 JMS client, which > raises some points for how we handle the overlap. We will obviously > continue to release it for some period, until we presumably drop back > to just having two JMS client again in form of the original 0-x client > and the new 1.0 client once it has matured a bit. Currently the older > 1.0 client is released along with the other components in the 'java > tree', such as the Java broker and the AMQP 0-x JMS client. We have > spoken about reorganising the source tree after 0.32 to better > facilitate independent releases of components. I did wonder if this > would also be an opportunity to make the older 1.0 client released > independently from e.g the broker and 0-x client, as it could then be > released more on-demand rather than on-schedule as presently. On the > other hand, this might make the naming thing more confusing since it > wouldn't simply be part of the 'java release' any longer and would > stand alone just like the new client, in which case leaving it part of > the 'java release' may actually be the simpler option. > > Thoughts? > > Robbie > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org > For additional commands, e-mail: users-help@qpid.apache.org > > --001a113575b83ce07c050fd71f15--