You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Brett Wooldridge <br...@gmail.com> on 2012/10/29 09:11:28 UTC

Derby release

Any ETA on a 10.9.1.1 release?  My company is waiting on the fix for
Derby-4279 ("Statement cache deadlock"), and we've got our own release in
about a month.  Would be great to pick-up this fix.

Alternatively, is there away we can compile our own 10.9.1.1 in a way that
will be updatable (DB file compatible) with an official version of the same?

Brett

Re: Derby release

Posted by Me <m....@gmail.com>.

On Oct 29, 2012, at 5:00 AM, Knut Anders Hatlen <kn...@oracle.com> wrote:

> Brett Wooldridge <br...@gmail.com> writes:
> 
>> Any ETA on a 10.9.1.1 release? My company is waiting on the fix for
>> Derby-4279 ("Statement cache deadlock"), and we've got our own release
>> in about a month. Would be great to pick-up this fix.
> 
> Hi Brett,
> 
> The dates haven't been decided yet, but there was some discussion about
> releasing 10.9.2 fairly shortly after 10.8.3. See this thread:
> 
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/201210.mbox/%3C5072F9D3.4040702%40sbcglobal.net%3E
> 
> End of November was mentioned. Not sure if that was meant to be the
> target for starting the vetting/voting or actually releasing it.
> 
>> Alternatively, is there away we can compile our own 10.9.1.1 in a way
>> that will be updatable (DB file compatible) with an official version
>> of the same?
> 
> With the caveat that we don't test that upgrade scenario, upgrade from
> an arbitrary point on a stable branch to a newer released version is
> supposed to work. So if you build your own jars from head of the 10.9
> branch, upgrade to 10.9.2 should in theory not cause any problems.
> 
> If you do that, you'll probably want to help testing the 10.9.2 release
> candidate to verify that it doesn't get released with a problem
> upgrading from your custom build. The upgrade tests in the repository
> have an option to run against custom builds, which would be a useful
> sanity check.
> 
> -- 
> Knut Anders

Hi Brett,

A few of us Derby developers met for an informal in San Francisco last month, and we did bring this up briefly then- not sure if I remembered to mention it when I reported on that lunch...But Lilly volunteered to manage that 10.9.2. 
But we're working on a 10.8 for (hopefully) November, and a 10.10 release, and I am dealing with a move of my testing machines, so I won't have the bandwidth to fully test a 10.9 until next year. 

That said, I routinely build jars that I deliver to my users as fix releases, and upgrading has always worked. 

Usually I tell my users just place these jars instead of existing ones, i. e., using soft upgrade...

Hth,
Myrna


Re: Derby release

Posted by Knut Anders Hatlen <kn...@oracle.com>.
Brett Wooldridge <br...@gmail.com> writes:

> Any ETA on a 10.9.1.1 release? My company is waiting on the fix for
> Derby-4279 ("Statement cache deadlock"), and we've got our own release
> in about a month. Would be great to pick-up this fix.

Hi Brett,

The dates haven't been decided yet, but there was some discussion about
releasing 10.9.2 fairly shortly after 10.8.3. See this thread:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/201210.mbox/%3C5072F9D3.4040702%40sbcglobal.net%3E

End of November was mentioned. Not sure if that was meant to be the
target for starting the vetting/voting or actually releasing it.

> Alternatively, is there away we can compile our own 10.9.1.1 in a way
> that will be updatable (DB file compatible) with an official version
> of the same?

With the caveat that we don't test that upgrade scenario, upgrade from
an arbitrary point on a stable branch to a newer released version is
supposed to work. So if you build your own jars from head of the 10.9
branch, upgrade to 10.9.2 should in theory not cause any problems.

If you do that, you'll probably want to help testing the 10.9.2 release
candidate to verify that it doesn't get released with a problem
upgrading from your custom build. The upgrade tests in the repository
have an option to run against custom builds, which would be a useful
sanity check.

-- 
Knut Anders