I'd say there are quite a few tasks aimed at 4.0. I just answered a thread
about jute.maxbuffer error, which could be improved for example. Or better
yet, throw jute out and use a standardized serialization library.
But there's also the issue of separating client and server code. And I'm
sure
Okay, let’s stay on JDK 8 with 3.7.0 release and do the transition in 4.0.
Not sure if we want 3.8 release or make the master 4.0 from now on.
Andor
> On 2021. Jan 6., at 22:35, Christopher wrote:
>
> I agree with Enrico on this point. If the ZK PMC is considering a 3.7
> release, now would
I agree with Enrico on this point. If the ZK PMC is considering a 3.7
release, now would not be the right time to make this change, and it would
be better to make a change at the beginning of the next iteration.
That said, I think switching to builds with JDK 11 and supporting JDK 8
"passively"
Also, software like ZK should lag rather than lead (I realize that moving
to 11 is hardly leading).
There is considerable pain that we inflict when we move JDK requirements
forward.
On Wed, Jan 6, 2021 at 10:20 AM Enrico Olivelli wrote:
> In my opinion we can stay on 8, we should change this
In my opinion we can stay on 8, we should change this kind of stuff at the
beginning of a new iteration and not before the release.
IIRC We are not in a hurry, having a stable build process is a value.
Enrico
Il Mer 6 Gen 2021, 17:51 Damien Diederen ha scritto:
>
> Dear ZooKeeper team,
>
>
Dear ZooKeeper team,
Andor just reminded me of this JDK 11 vs. 8 discussion, for which we did
not reach a resolution. Do we want to make a move for the 3.7.0 release?
The original proposal, by Christopher, can be found here:
