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