Thanks for the response, Patrick. Considering that, it sounds like recursive ls is a non-starter for 3.4, but we can focus on shipping it in 3.5. I'll focus on that in the code reviews.
--Chris Nauroth On 12/8/15, 4:12 PM, "Patrick Hunt" <[email protected]> wrote: >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 >
