Hi all, Arnold raised some fair points, so I will proceed as follows:
Step 1: Revert of PR #5021 <https://github.com/apache/fineract/pull/5021>, since it can be considered a breaking change in our Docker image deployment and deserves further discussion. The revert PR is here: #5042 <https://github.com/apache/fineract/pull/5042>. Step 2: Using GitHub CI, I will regenerate the removed Docker tags to avoid further disruption for anyone relying on them. Step 3: Open up a discussion on whether we want to make changes to the way Docker images are handled for Apache Fineract going forward. Regards, Adam > On 2025. Sep 17., at 16:28, James Dailey <[email protected]> wrote: > > The docker builds are provided as a convenience, just as the binaries are. > The official release processes are required by ASF as the custodian entity > for the project. It would be more appropriate to have a better release > process so we can do this at least quarterly. > > Please see my other thread about the need for build automation. > > As for the tags on Docker, I do think Adam S could have provided more > discussion, but he dug into it and fixed something - that's the intent and I > trust that everyone understands the good intentions. > > Moreover, the transparency that is now enabled is better than before.. and > having a cluttered set of tagging that has nothing to do with an actual > release is not useful, and from what I am reading may give a false sense that > each tagged build is somehow a "release". They're not. We cannot pretend > that they are. > > The project can discuss how to use Docker, or not. > > Again, the docker images are merely a convenience we do - not a release. > Let's aim to improve both. > > On Wed, Sep 17, 2025 at 6:47 AM Arnold Galovics <[email protected] > <mailto:[email protected]>> wrote: >> 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 <https://docktape.com/> >> Docktape Technologies >> >> >> >> >> On Wed, Sep 17, 2025 at 3:37 PM Ádám Sághy <[email protected] >> <mailto:[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] >>>> <mailto:[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 <https://docktape.com/> >>>> Docktape Technologies >>>> >>>> >>>> >>>> >>>> On Wed, Sep 17, 2025 at 2:54 PM Ádám Sághy <[email protected] >>>> <mailto:[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 >>>>> >>>
