db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: 10.8.2 coming even closer
Date Fri, 09 Sep 2011 14:52:05 GMT
On Fri, Sep 9, 2011 at 2:43 AM, Knut Anders Hatlen
<knut.hatlen@oracle.com> wrote:
> Knut Anders Hatlen <knut.hatlen@oracle.com> writes:
>> Myrna van Lunteren <m.v.lunteren@gmail.com> writes:
>>> https://issues.apache.org/jira/browse/DERBY-5236 (Knut): On Sep 1,
>>> Knut wrote "I'm not sure if a complete fix will be in place for 10.8.2
>>> (or if the complete fix will be suitable for backport since it may
>>> involve protocol changes), but I intend to backport as much as
>>> possible of the code in this issue."
>>>     current status: the following commits went into trunk: 1104365,
>>> 1163131, 1164495, and a patch is ready for review. No backports to
>>> 10.8 yet.
>>>     I'm still hoping this will make it into 10.8, but won't wait the
>>> release for it.
>> I plan to commit the current patch tomorrow morning, if there are no
>> objections. Then I'll add a little bit of code to make sure that the new
>> server code doesn't break old clients (essentially disable the
>> server-side fix when talking to an old client). If that doesn't cause
>> any breakage in nightly tests over the weekend, I'll backport all the
>> fixes to 10.8 on Monday morning just in time for the RC.
> The logic that disables the fix when talking to older clients, needs to
> check the version of the client. Since the server currently only
> supports checking the first three digits of the version number, I've
> coded it so that the fix will be enabled on 10.8.2 and newer. This means
> I will have to bump the version number on the branch from to
> when I backport the fix, otherwise the regression tests for the
> fix will have to be disabled on the 10.8 branch until the RC is
> produced. Myrna, do you see any problem with my bumping the version
> number on the branch to 10.8.2 before you create the RC?
> Alternatively, it might be possible to make the server support checking
> all four digits in the version number and just bump the last digit. But
> given that the RC is scheduled shortly thereafter, it doesn't sound
> worthwhile to add code just to allow the branch to stay at 10.8.1.x for
> a couple hours extra.
> --
> Knut Anders

I don't see a problem with increasing the 3rd digit...
If it gets in the way (although I can't see why it would), I can
always up the fourth digit and declare the first 10.8.2
candidate instead of


View raw message