That suggestion works for me in general. The only question would be around whether the other components in the 'java' tree alongside it currently would have to be released as well (the broker and other client would also be deployed curently by the parent 'java build'), or whether you would trim the client off out on its own?
Robbie On 24 February 2015 at 15:24, Rob Godfrey <[email protected]> wrote: > 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 <[email protected]> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
