The process I use is to d/l an official release (the one I need to provide a patch for), apply the patch and rebuild ("ant tar" is what we use for official releases). I typically try to keep the change delta small, document the baseline and patches applied, and encourage users to upgrade to an official version including the required fixes asap.


On 07/29/2010 05:44 PM, Vishal K wrote:
Hi Patrick, Mahadev,

We would like to apply critical patches asap. For example, this bug was
preventing a failed node to rejoin the cluster. In such cases, it won't be
possible to wait for the next version. What process do you suggest to be
follow in such a case?  I am not restricting the discussion to this
particular bug (say I was using 3.2.2 or older version).


On Thu, Jul 29, 2010 at 6:12 PM, Patrick Hunt<>  wrote:

To be clear we are shooting for a release candidate next week, it will take
a few days after that to go through the process before an official release
is available.


On 07/29/2010 02:22 PM, Mahadev Konar wrote:

HI Vishal,
   There is patch available for 3.3 branch which I think should apply.

On the other hand its not a good idea to have run your own patched version
of ZooKeeper in production. 3.3.2 should be out by next week, you might
to wait for that and then use it.


On 7/29/10 1:48 PM, "Vishal K"<>   wrote:


What would be the right way to apply a zookeeper patch. For instance, if
am using zookeeper-3-3.0 and I would like to apply a patch for
to this version.
However, I presume that the patch that I have is generate from the trunk.
there a way I can get a patch specific to zookeeper-3-3.0?


Reply via email to