KMyMoney 5.0.5 released

Jack ostroffjh at
Thu Jul 11 18:32:34 BST 2019

To really understand all of this, you have to understand how git works, 
and how it is usually used, especially in much larger projects than 
KMM.  In general, master is the "most cutting edge" branch.  A developer 
might create a separate branch for interim work on some large new 
feature, where much of the time it is not expected to compile or to 
work.  Once the feature mostly works, it is merged into master.  (The 
criteria for "mostly" is up to each project team.)  Once a major release 
of an application is ready, a separate branch is usually/often created.  
For applications that have LTS versions, there may be a branch for the 
LST version, the most recent version, and master.  (Actually branches 
for the series, not the single version.)  Bug fixes are applied to the 
branch for the version which has the bug, and then copied to branches 
for later versions, unless the fix would no longer apply, due to code 
changes or feature changes.  When master does not diverge very much from 
a version branch, as is the case with KMM, commits can be made to either 
master or 5.0.  The difference, as Thomas stated, has to do with the 
effort of applying a commit from one branch to the other.  Applying a 
single commit uses "cherry pick" which thus needs to be done for each 
commit to be applied. On the other hand, if all recent commits in one 
branch are to be applied to the other branch, it is easier to do a git 
"merge."  In our case, merging 5.0 into master works fine.  However, 
since there are some (even if not many) commits to master (new features 
for example) which should NOT be copied back to 5.0, the merge cannot 
safely be done in that direction.

Any given commit (bug fix) may be applied first to either 5.0 or master, 
and the delay in it being copied to the other branch should rarely be 
longer than a few days or a week, so the only time it really matters is 
if you immediately want to test a given bug fix.  In that case, you do 
need to pay attention to where it was committed.  However, as Thomas 
also implied, versions compiled from master and 5.0 may not behave 
exactly the same.  Although all the developers try to avoid any 
significant breakage, it happens, but is more likely to happen in 
master, or perhaps better stated less likely to happen in 5.0 branch.  
(The difference is just a matter of perspective.)

Hopefully this adds some clarity, and doesn't just make more confusion.  
Sorry to be so long-winded about this, but once you have been working 
with git for a while, you sometimes forget that things were not at all 
obvious when you started - it is only by actually working with it (and 
making the occasional mistake) that you stop thinking about (or needing 
to think about) the details.


On 7/11/19 12:04 PM, Brendan Coupe wrote:
> I'm more confused than I was before I asked the question:-) I have
> been using 5.0 lately since that's where the changes seem to end up
> first. Seems like that makes it 5.0 more cutting edge and when things
> work they get merged into the Master, making it more stable but that
> was my first guess and you said I was wrong.
> The link you sent ( does not clarify
> this at all for me since there is no mention of either the 5.0 or
> Master branch. How about simply adding the branch to each description
> as I have done below - look for (XXX Branch):
> ========================================
> For Linux users, who want to use a newer version than is available in
> their distro repository, we offer an AppImage version which reflects
> the current stable version (XXX Branch) including the latest fixes. It
> is build on a daily basis straight from the source.
> Here's how you install and run it:
> Download the file from
> to
> any location you like.
> Change into the directory where you downloaded the file.
> Make the file executable with chmod +x name-of-downloaded-file.
> Execute the file with ./name-of-downloaded-file.
> For the very adventurous Linux user, there is an AppImage with the
> latest development version (XXX Branch) at
> ----
> Brendan Coupe
> On Thu, Jul 11, 2019 at 1:35 AM Thomas Baumgart <thb at> wrote:
>> On Donnerstag, 11. Juli 2019 03:02:04 CEST Brendan Coupe wrote:
>>> That's what I thought but I thought some of the recent changes Thomas
>>> made for me ended up in the 5.0 branch before they made it to the
>>> Master branch.
>> Yes, that is true. Using git, one can merge a branch (A) into another (B). That means, that all changes in (A) go into (B).
>> For KMyMoney at the moment I use 5.0 as (A) and master as (B). So far, we don't see massive conflicts as the code base is pretty similar.
>> Using it the other way around, all changes of master (unstable) will end up in 5.0 (stable) which is not what I/we want as master already contains code that is not in a state I would call stable - even though it might be working w/o problems. There is more of it here on my local system which is not yet complete and sometimes not compilable/workable so I don't want to add that to master as of yet.
>> So adding fixes of bugs to the 5.0 branch and merging 5.0 now and then back to master is what I/we do. If a fix goes into master and we want to have it on 5.0 we need to cherry-pick each one of them individually. Merging OTOH is one operation. See
>>    git log 8e49874f..ce17b1ee
>> for such a cherry-pick example which happened lately. Hope that explains it.
>> Note: I use 5.0 as my production environment and master for future development. You should probably do the same ;)
>> Thomas
>> --
>> Regards
>> Thomas Baumgart
>>       Signal, the better WhatsApp
>> -------------------------------------------------------------
>> BTW, just the planning of the test cases helped me
>> to improve the code a lot. -- Alvaro Soliverez
>> -------------------------------------------------------------

More information about the KMyMoney-devel mailing list