Personally I'd probably release that client independently from the rest of the java tree unless we happened to coincidentally want a patch release of the rest of the Java tree at the same time.
Post 0.32 I think we are probably thinking of doing incremental patch releases off the 0.32 branch for Java components if/when significant defects come about (making 0.32 a sort of long term support version). From trunk we'll be starting on the great directory re-org so that as previously discussed, going forward we'll be doing independent releases between Java and C++ at a minimum, and possibly at an even finer granularity. -- Rob On 25 February 2015 at 17:05, Robbie Gemmell <[email protected]> wrote: > 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] > >
