Hi Adam, Let's put back the tags as soon as possible. If somebody was relying on them, now their deployment might be broken (which again, disapproves the use of the community Fineract but further enhancing the importance of rather forking it).
> *Here’s my perspective: even if we go back to producing Docker tags for each commit, any bugfix is always based on the latest develop branch anyway. In practice, there’s little difference between pulling the latest tag and pulling a commit-specific tag like a2c66e6c319e8c7b0e335d6d35d47c893abc353c (which, for example, contains the recent bugfix for FINERACT-2353). Both represent the state of develop at that time.* There's one fundamental difference though. Reproducibility. If a deployment is based on "latest" - let's assume a Kubernetes deployment/ECS deployment/even a simple docker compose deployment, a simple restart could produce a very different version then it was before. It's unsustainable. > *Also, it’s worth emphasizing that these builds are not official Fineract releases. They’re essentially snapshots of ongoing development, with the 1.x tags reserved for actual releases.* Agreed, they are snapshots. But the reason they are so important is because we - as a PMC - haven't defined any predictable, quick ways to reliably produce Fineract releases, hence people need to take this into their own hands and rely on "snapshots". To be honest, I'm really surprised this has been done without any preliminary discussion and analysis and was kind of a reckless move in my mind. Let's try not doing this in the future. Such a backward incompatible change - which could affect hundreds of deployments - must be discussed beforehand. Again, Adam, this is nothing against you, it's just one of the indicators that Fineract doesn't have such mature processes yet - which in turn and I keep repeating myself here, forces people to rather fork Fineract and do their thing in the fork. Best, Arnold Arnold Gálovics *CEO, Co-Founder* *+36 30 904 1885* https://docktape.com Docktape Technologies On Wed, Sep 17, 2025 at 3:37 PM Ádám Sághy <[email protected]> wrote: > Hi Arnold, > > Thanks for raising your concerns! > > Yes, the tags were removed. I was just about to share more context, as > Docker Scout has been enabled on the project, and with hundreds of tags the > visibility became really poor. > > Since we’re already on the topic (and I admit, a bit later than I should > have brought it up—my bad!), it’s worth discussing whether we really want > to create and maintain a tag for *every* commit on the develop branch. > > Here’s my perspective: even if we go back to producing Docker tags for > each commit, any bugfix is always based on the latest develop branch > anyway. In practice, there’s little difference between pulling the latest tag > and pulling a commit-specific tag like > a2c66e6c319e8c7b0e335d6d35d47c893abc353c (which, for example, contains > the recent bugfix for FINERACT-2353). Both represent the state of develop at > that time. > > Also, it’s worth emphasizing that these builds are not official Fineract > releases. They’re essentially *snapshots* of ongoing development, with > the 1.x tags reserved for actual releases. > > That’s the reasoning behind the cleanup, and I hope it clarifies my > thinking here. Of course, I’m open to further discussion if the community > feels strongly about commit-based tags. > > Best, > Adam > > On 2025. Sep 17., at 15:14, Arnold Galovics <[email protected]> > wrote: > > Hi Adam, > > Does this mean the "legacy" tags were deleted from DockerHub too? > > Why was removing the commithash-based tags deprecated and removed? I don't > think we had a discussion around this. > > Originally I was the one introducing the commit-hash based tags for both > Fineract and for the Mifos UI because what we all can agree on is that we > have infrequent releases. > > As long as we don't have a predefined release train for the next 6 months, > preferably with monthly releases, I just don't see how anybody can > effectively rely on Fineract releases. > > Imagine you have a client who uses Fineract. There's a bug. You fix it, > open a PR, merge it to the develop branch and that's all. Bug is fixed, > nothing is released, the bugfix cannot be applied to your client since you > don't have an official release of Fineract which includes the fix. Waiting > for 6 months for a new release? Unrealistic. > > In my opinion this rather incentivizes forking Fineract completely and > never looking back. As long as we don't make it easy for clients to grab > the latest things easily (and "latest" is not an option, because it always > moves and companies want predictable things), we're pushing people off from > building a strong (client) community. > > Let me know if I misunderstood something. > > Best, > Arnold > > Arnold Gálovics > *CEO, Co-Founder* > *+36 30 904 1885* > https://docktape.com > Docktape Technologies > > > > > On Wed, Sep 17, 2025 at 2:54 PM Ádám Sághy <[email protected]> wrote: > >> Dear fellow Fineracters, >> >> We’ve recently reworked how Docker images for Fineract are published >> (thank you "Akshat-Soni02 >> <https://github.com/Akshat-Soni02/Akshat-Soni02>”, “javamak”) : >> https://github.com/apache/fineract/pull/4969 >> >> https://github.com/apache/fineract/pull/5021 >> >> *Summary of changes:* >> >> >> - >> >> The latest tag now always points to the most recent build of the >> develop branch (automatically updated with each push). >> - >> >> Versioned tags like 1.12.1, 1.12.0, etc. correspond to official >> releases. >> - >> >> Legacy tags (e.g., commit hashes and other intermediate builds) have >> been cleaned up. >> >> This maintenance was long overdue, and we hope the new structure makes it >> easier and clearer to use our Docker images. >> >> Please let me know if you are missing any “earlier” releases, and I will >> build and upload manually the missing versions. >> >> Best regards, >> Adam >> > >
