Arnold - obviously, we're all trying to work for NOT having forks, and having upstream contributions. I mean, that's been my intention for the past two decades and I really would like to solve that.
So, right, what are the barriers? What improves the picture? What are the next incremental steps to focus on getting it right? DockerHub Docker Hub I noted in an April 2024 report, was completely broken. I mean, when I looked at it, the build had not passed in more than 24 months. Now, the build is passing and thanks to Victor, is working at the Apache namespace for DockerHub. This is great. And for more than a year it has been generating something useful. Now, we are adding Docker Scout. Release process I agree 100%, and as I said, the Release process must be MUCH better. With help, I got out the 1.9 and 1.10.1 releases over a 10 month period - it taught me that the release process was really too difficult. At the Apache Conference CoC2025 this past weekend, I met some folks from Grails, which came into ASF and in 18 months has done something like 24 official releases. They have an automated release process - see https://lists.apache.org/thread/767n32q7dnwkm5mrdoqtq4yf3bqy7sb4 <https://lists.apache.org/thread/767n32q7dnwkm5mrdoqtq4yf3bqy7sb4> for my action items. We should aim for AT LEAST quarterly, predictable releases. Those releases should also be pushed to DockerHub with all the necessary promotion on our fineract website as well. We must follow ASF release processes, and so if someone is grabbing Docker images that is NOT a signed release, then it shouldn't be considered as such. I think there are other regulatory and compliance issues involved as well... but more on that, as well as SBOM and bugfixing ==> https://lists.apache.org/thread/d7vz25qvmcp4qk7mxw5x682284yl2w3y And those releases should be "production ready", having passed all of our tests. Next How do we get to that ideal situation? Is the above enough of a description? James Dailey On Wed, Sep 17, 2025 at 7:46 AM Arnold Galovics < arnold_galov...@docktape.com> wrote: > James, > > I did not say that the commit-hash tagged Docker images are official > "releases" because they are not, although I'd like to think about the > develop branch as a continuous flow of development which always hits the > quality required for a release a.k.a. as a fully fledged release candidate. > But that's on for another discussion. > > My point is, due to the lack of predictability in releases (plus the > usually missing bugfix releases) people and companies rely on the "latest" > version of Fineract but with a specific tag. As I said before, > reproducibility is key for any environment. > > I'm fine with dropping this support as long as we understand the > consequences. Fineract is already a heavyweight player on the field with a > high probability of forking it and companies maintaining their own versions > which never make it back upstream. If we wanna keep pushing people this > way, I'm fine with that too, just make it a conscious decision. > > Best, > Arnold > > Arnold Gálovics > > *CEO, Co-Founder* > > *+36 30 904 1885* > > https://docktape.com > > Docktape Technologies > > > > > On Wed, Sep 17, 2025 at 4:43 PM Ádám Sághy <adamsa...@gmail.com> wrote: > >> *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 <jdai...@apache.org> 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 < >> arnold_galov...@docktape.com> 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 >>> Docktape Technologies >>> >>> >>> >>> >>> On Wed, Sep 17, 2025 at 3:37 PM Ádám Sághy <adamsa...@gmail.com> 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 < >>>> arnold_galov...@docktape.com> 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 <adamsa...@gmail.com> 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 >>>>> >>>> >>>> >>
