On 10 April 2013 16:45, Justin Ross <[email protected]> wrote: > On Wed, Apr 10, 2013 at 10:44 AM, Rob Godfrey <[email protected]> > wrote: > > > OK - these would seem to be sensible policies to apply in future... but > > obviously they've not been clearly defined or consistently applied in the > > past. > > Not clearly defined, yes. I think they have, however, been > consistently applied. I went back and looked at 0.20, for instance, > and I rejected improvements after RC1. It's widely accepted practice > to avoid putting anything but bug fixes in release candidates. > Indeed, Robbie's requests have generally followed this model as well. > > > From the point of view of the current Java developments, we have a number > > of changes that we would want to go out in this release since > > > > a) they are scheduled to be completed within the next few days > > b) they are isolated to the configuration and management ares and > therefore > > of very low risk to core functionality > > c) if not released in 0.22 will require the generation of upgrade scripts > > for users of 0.22 when they take the next version. > > d) would require us to document everything that changes twice - once for > > the interim change which would go out in 0.22 (which is different to > 0.20) > > and then again for 0.24 > > Item A suggests you have further improvements to make. This sounds > like it calls for an overall schedule adjustment. The isolation to > management is helpful, but since it's a feature of the software that's > already released and in use, there's risk of impacting its users. > > I think what Rob meant as to the schedule is that the current timeframe we seem to be on for the actual release date is not expected to be impacted by the changes being discussed.
Most of what we are talking about further change to has not previously been released, and so is actually not in use by users currently. The HTTP management interface has been previously released, yes, but all the functionality under discussion has not and is part of the new configuration model/aproach which was added in this cycle. It is for this reason we would prefer to make these final changes rather than release it in in its current almost-there state, as it then will impact users when we have to change the management interface and configuration files again in the very next release. There is also to the impact to ourselves as far as the extra work required to make the changes in a subsequent release. > > Given the infrequency of our releases and the extra hassle for our users > > of releasing with what are essentially incomplete changes, we would > > strongly prefer to include the completed changes in 0.22. From our > > perspective there would likely be little issue with hitting the dates for > > 0.22 by doing so, but obviously the inclusion of these patches would > > violate the release guidelines that are now being proposed. > > > > Obviously in the longer term the work we are looking to do around > > modularization and decoupling the releases would make such issues less > > likely in the future... But given that the very act of modularizing the > > code may impact our next release I would very strongly like us to make > 0.22 > > a coherent package as far as the Java side is concerned - and to me that > > would mean including this small set of management changes that Robbie and > > Alex are currently working on. > > > > What would your thoughts on a way forward be? > > Well, there's the 0.22.1 path, which isn't addressed here. I don't > think there's anything wrong with doing that. > > If we are prepared to do a 0.22.1 release (and I certainly am, having long thought we should do point releases, I'd even volunteer to release manage them) then that would make me more inclined to include the changes being discussed in 0.22. Deferring the changes into any future release creates additional change for our users and additional work for ourselves to accomadate those changes, so if we are prepared to do a further release I would prefer to use it to resolve any issues with 0.22 (across all the components, not just the Java broker, which would benefit all our users). > It's clear that you are willing to own the outcome, so in the end it > only makes sense to let you do with the RCs what you want. > > Justin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
