Hi Maurício,
Thank you for raising this — your concern is valid, and I think many of us share it.
You are right that, from the outside, Harbour can look stagnant: the last official stable release is 3.0.0 (July 2011), while the development tree has been at 3.2.0dev for many years. That gap creates a perception problem, even for people who use the project daily and know it is actively maintained.
However, I would not describe Harbour as abandoned. If you look at the current repository (
github.com/harbour/core (
https://github.com/harbour/core)), you will find:
• Regular commits (including fixes as recent as May 2026)
• CI builds on Linux, Windows, macOS and additional VM environments
• A maintained ChangeLog.txt with detailed entries
• Packaging infrastructure already in place (package/mpkg_src.sh, HB_BUILD_PKG=yes, nightly Windows binaries on SourceForge)
• An active contributor base (Czerpak, Szakats, Czajczynski, and others)
So the bottleneck has never been lack of development — it has been the release process itself: deciding what qualifies as "stable", testing across all supported platforms/compilers, preparing binaries, writing release notes, updating SourceForge, and coordinating it all with a small group of volunteers with limited time. That is why past discussions ended at "it is too much work."
On your point about AI: I agree it can reduce the mechanical burden significantly — generating release notes from ChangeLog.txt, preparing packaging scripts, drafting checklists, even helping triage regressions. But you are also right that it cannot replace Harbour expertise. Someone who understands the compiler, RDDs, GTs, cross-platform quirks, and backward-compatibility guarantees still needs to review and sign off. AI accelerates the process; it does not remove the need for a maintainer.
For practical purposes today, users who want something newer than 3.0.0 can use:
• The nightly Windows builds (updated daily from master)
• A fresh clone of the Git repository
But I fully agree that this is not the same as having a proper 3.2.0 stable (or similar) that outsiders can point to.
If there is interest in reviving the release discussion, the right place is indeed the Harbour developers' mailing list. A realistic first step would not be a perfect release, but a scoped one: pick a snapshot of master that passes CI, flip HB_VER_STATUS from "dev" to "" (or "rc1"), run the existing packaging scripts, and publish. AI can help with everything around that — changelog curation, release notes, regression checklists — while core maintainers focus on the technical sign-off.
Thank you again for bringing this up. The perception matters, and so does having a clear, downloadable stable version.
Best regards,
Antonio