qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: towards releasing the new AMQP 1.0 JMS client
Date Tue, 24 Feb 2015 15:24:59 GMT
So, I'm very much in favour of getting the new client released as soon as

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

Does anyone object to this plan?

-- Rob

On 18 February 2015 at 13:33, Robbie Gemmell <robbie.gemmell@gmail.com>

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message