On Fri, Sep 9, 2011 at 2:43 AM, Knut Anders Hatlen <[email protected]> wrote: > Knut Anders Hatlen <[email protected]> writes: > >> Myrna van Lunteren <[email protected]> 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 10.8.1.6 to > 10.8.2.0 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 10.8.2.1 the first 10.8.2 candidate instead of 10.8.2.0. Myrna
