Good idea. Agree on including anything we've postponed to a new cycle - the patch from mapr is an obvious one to consider.
We should also look at things we've disabled by default and consider whether we can turn them on by default. If not why not, and what can we do to fix this in a subsequent release. Have we deprecated anything that we should now remove? Also a good time to review the state of Java versions and make changes wrt supported versions and so forth. There was a proposal to remove contribs, or at least consider the ones that are still valuable vs moving some out. We should do that as well. Regards, Patrick On Sat, Jun 15, 2019 at 9:02 AM Jordan Zimmerman <jor...@jordanzimmerman.com> wrote: > On Persistent/Recursive watches: I’m willing to rebase, etc if there’s > confidence it will be merged. > > ==================== > Jordan Zimmerman > > > On Jun 15, 2019, at 10:59 AM, Andor Molnar <an...@cloudera.com.invalid> > wrote: > > > > Hi Enrico! > > > > Very good point, I entirely support the idea. > > > > Question to Friends@Facebook and Twitter contributors: how many > outstanding > > Jiras/PRs do you have which you would like to see in 3.6? > > > > I'd also like to highlight the long outstanding PR from Mapr: > > https://github.com/apache/zookeeper/pull/730 > > > > And some great new features which are still looking for to be merged: > > - Persistent recursive watchers: > > https://github.com/apache/zookeeper/pull/136 > > - Enforce client auth: https://github.com/apache/zookeeper/pull/118 > > - Slow operation log > > - Jetty port unification > > > > Regards, > > Andor > > > > > > > > > > > >> On Sat, Jun 15, 2019 at 1:31 PM Enrico Olivelli <eolive...@gmail.com> > wrote: > >> > >> Hi Zookeepers ! > >> I checked on JIRA and it seems that master in good shape, no real > blockers > >> that mine the stability of the code. > >> > >> We have plenty of cool pull requests almost ready to be merged (mostly > from > >> Facebook friends and Twitter fork) > >> > >> Current master branch is full of great features in respect to 3.5. > >> > >> AFAIK There is no incompatibility with 3.5 so it is okay to stay with > >> 3.6.0, although I think that there is so much stuff to legit a switch to > >> 4.0.0 (but we can reserve such bump for the time we will separate the > java > >> client and create a minimal compatibility breakage) > >> > >> Thoughts? > >> > >> Enrico > >> >
