On Tue, Dec 8, 2015 at 3:01 PM, Chris Nauroth <[email protected]> wrote: > Do we have any kind of policy regarding adding new public APIs in the 3.4 > stable maintenance release? Adding a new API won't harm > backwards-compatibility, but it does mean that an upgraded client can't use > the new API until the server side gets upgraded too. I'd expect adding a new > API is overall OK, subject to standard risk assessment for any patch going > into a stable maintenance line. >
Hi Chris. It's always been the case that we only allow fixes in fix releases. Things like API changes are always introduced in minor releases, and they need to be backward compatible. Major releases are for cases where we need to break b/w compat (which hasn't happened since we moved to Apache). Patrick > ZOOKEEPER-1962 proposes enhancing the CLI to support recursively listing > children. However, running this on a large tree would risk hitting the > jute.maxBuffer threshold, consuming a lot of memory, and consuming a thread > for a long time to process the request. I'd like to propose that > ZOOKEEPER-2260 (paginated getChildren) be a pre-requisite for the CLI > enhancement, so that we can avoid these problems. However, I'd also like us > to try to ship the feature in a future 3.4 release, because it's very useful > for operators. This is the main motivation for my policy question about > adding new APIs in a stable line. > > --Chris Nauroth
