On 8 April 2013 22:40, Justin Ross <[email protected]> wrote: > On Mon, Apr 8, 2013 at 4:09 PM, Rob Godfrey <[email protected]> > wrote: > > The other changes (which I made) I can take or leave... the GUI change is > > obviously trivial, but clearly not a blocker. The SASL for AMQP 1.0 > would > > be nice to have in terms of improving 1.0 support, but again clearly not > a > > blocker. > > > > As an aside, do we have a document somewhere describing our policy for > what > > is or is not acceptable in each RC version? > > No, there isn't, and that's my fault. I'll add this to the standard > release page content, but to summarize my thoughts here: > > - Trunk open to alpha - Go wild, cowboy > - Alpha to beta - Major features, improvements, or refactorings need > discussion before they can go in > - Beta to RC1 - This should be bug fixes only; I tend to be more > lenient in this phase as long as there are other positive indications > (isolation, minimal diff) > - RC1 to GA - Bug fixes only, and they really ought to be important > defects (build failures, regressions, vulnerabilities) > > 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.
>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 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? -- Rob > Justin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
