Those are all fine alternatives.
I suspect that if Derby worked well as a testbed for the last decade, it
will continue to work well for the next decade, even without an active
community behind it.
On 9/24/25 2:44 PM, Clebert Suconic wrote:
so, I spoke to folks on our slack channel for ActiveMQ.
We use it for our testsute, and never in production... We can easily
replace it by either dockerized databases (e.g Mysql or Oracle), or
use HSQL / H2.
We would be happy to use it if there's still a community around it,
but if there's not enough community (devs) to keep the project going,
we couldn't find anyone at ActiveMQ willing to maintain it.
We will just watch this space and decide based on the outcome here.
On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic
<[email protected]> wrote:
I just opened a discussion on ActiveMQ dev list. I would -1 on
retiring it. I'm not active on this co0debase, and I wonder what would
be required to keep it alive?
I hope some other members from the ActiveMQ community could jump on
this discussion as well.
On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic
<[email protected]> wrote:
I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ
class, for our tests.
As part of our testsuite, I need to validate our basic SQL interfaces
would work as required.. it has been a good tool for our testsuite.
If you intend to retire Derby I wonder what I would use into our
testsuite validation though?
On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi <[email protected]> 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?
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.
Stick with 10.14.2.0. It's possible that some change in a latter version could
cause a problem.
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.
Move to one of the other embeddable RDBMS. (Which would you recommend?)
We are eternally grateful to Rick, Bryan, and the Derby community. It's a
wonderful piece of software.
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
--
Clebert Suconic
--
Clebert Suconic
