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. > 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. 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]
