Hi Rick, I'm currently using version 10.15.2.0 with Java 11 in production. Can this version also be considered stable and reliable like the 10.14.2.0 you mentioned? Also, are Derby versions strictly tied to the JVM version for optimal performance? Could I theoretically use 10.14.2.0 (which targets Java 8) with Java 11, or is it better to stick with 10.15.x which is specific for Java 9+?
Thanks On Thu, 25 Sept 2025 at 01:04, Rick Hillegas <[email protected]> wrote: > Some comments inline... > > On 9/24/25 11:53 AM, Jerry Lampi wrote: > > We use Derby daily. Our customers use Derby daily. > > Our sentiments precisely match Roy Minet's: > > "Retiring Derby" sounds unnecessarily scary. What it means is ending > further development and support, but Derby will continue to be alive, well, > and available. Is that correct? > > The source code will still be available via subversion. The website will > still be available, containing a wealth of information, including full > documentation on all release families. > > The following resources, however, will disappear: > > o Apache-hosted Derby distributions will no longer be available. > Nevertheless, I expect that distros will still be available from the > maven artifactories. > > o Apache-hosted Derby mailing lists will no longer function, although > their twenty-years of archives will still be browsable. Questions about > Derby should be directed to general-purpose support forums. > > o There will no longer be an Apache-hosted mechanism for logging new > bugs or bug fixes. However, old bug reports will still be browsable via > read-only JIRA. > > > > > I have used Derby for years and have yet to have any problems with it. I > employ a good range of SQL capabilities, but try to avoid (what I would > consider) excessive complexity. Derby is good and valuable software and I > thank you profusely for it! > > > > I'm about five years behind (using 10.14.2.0), but have not so far been > motivated to move to a latter version (if it ain't broke, don't fix it). Of > course, there are alternatives to Derby as well, but I have not so far seen > any reason to change. What I am most interested in is your advice for > someone in my situation. > > > > > > 1. Stick with 10.14.2.0. It's possible that some change in a latter > version could cause a problem. > I would stick with 10.14.2.0 as long as you can remain on Java 8. I > agree that there's no point in fixing something that already works well > for you. When the time comes to upgrade to a later Java version, you can > download the corresponding Derby version from the maven artifactories. > In a pinch, you can always download the Derby source code from the > appropriate subversion-managed release branch and build the jar files > yourself. Each release branch describes the exact steps for doing this. > > 2. Move to (the apparently final version) 10.17.1.0 and > "standardize" on that. There are some enhancements and bug fixes in there > that I may encounter the need for in the future. > The final version is the unreleased development mainline (10.18.0.0). I > have successfully tested the development mainline against the latest LTS > Java version (JDK 25, see > https://issues.apache.org/jira/browse/DERBY-7175). Oracle has committed > to maintaining Java 25 until 2033, according to > https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > 3. Move to one of the other embeddable RDBMS. (Which would you > recommend?) > I have no recommendation. > > > > We are eternally grateful to Rick, Bryan, and the Derby community. It's > a wonderful piece of software. > Thanks, much appreciated. > > > > Jerry Lampi > > > > ________________________________ > > From: Rick Hillegas <[email protected]> > > Sent: Monday, September 22, 2025 12:26 PM > > To: [email protected] <[email protected]>; Derby Discussion > <[email protected]> > > Subject: [DISCUSS] Retiring Derby > > > > It has been almost two years since the Derby sub-project published a new > > version. I myself have no interest in managing another Derby release. > > Bryan is the only other active Derby committer. Bugs are reported > > occasionally but they are never fixed. Mailing-list activity consists > > almost entirely of spam rejects. No-one has volunteered to refresh the > > Derby website with the new Apache logo. > > > > I think that the time has come to retire Derby. As I understand it, this > > means putting Derby into a read-only state: > > > > o The Derby repository would become read-only. > > > > o Distributions would be removed from the Download tab. > > > > o The developer and user lists would be closed down. Mailing list > > archives would still be browsable. > > > > o A prominent banner would be added to the Derby website landing page, > > stating that Derby was now retired and read-only. > > > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > > > Before calling a retirement vote, I would like to give the developer and > > user communities an opportunity to discuss this change. > > > > What are your thoughts? > > > > -Rick > > > > > > > > > >
