KMyMoney 5.0.5 released

[Brendan Coupe]

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 (https://kmymoney.org/appimage.php) 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
https://binary-factory.kde.org/job/KMyMoney_Stable_Appimage_Build/ 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
https://binary-factory.kde.org/job/KMyMoney_Nightly_Appimage_Build/.

----
Brendan Coupe

On Thu, Jul 11, 2019 at 1:35 AM Thomas Baumgart <thb at net-bembel.de> 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
>
> https://www.signal.org/       Signal, the better WhatsApp
> -------------------------------------------------------------
> BTW, just the planning of the test cases helped me
> to improve the code a lot. -- Alvaro Soliverez
> -------------------------------------------------------------