KMyMoney 5.0.5 released

Andrew Ho andrewho at
Thu Jul 11 20:21:32 BST 2019

This is the different I find from kmymoney-master and kmymoney checkout 5.0

It is the only CMakeList.txt.

I haven't compared all the files of these two directories.

--- kmymoney-master/CMakeLists.txt?????????? 2019-07-11 15:12:35.350637767 -0400
+++ kmymoney/CMakeLists.txt???????? 2019-07-10 21:46:16.442365582 -0400
@@ -2,7 +2,7 @@
 ??cmake_minimum_required(VERSION 3.1)

 ??# Setting the name of the main project
-project(KMyMoney VERSION "5.0.80" LANGUAGES CXX)
+project(KMyMoney VERSION "5.0.5" LANGUAGES CXX)

 ??# Determine the GIT reference (if we're based on GIT)
 ???????? message(FATAL_ERROR "This version of KMyMoney requires at least 
gcc 6.0.0 to be built successfully")

-find_package(ECM 5.42 REQUIRED NO_MODULE)
+find_package(ECM 5.10 REQUIRED NO_MODULE)

@@ -54,9 +54,9 @@ find_package(PkgConfig)
 ??set (OPT_KF5_COMPONENTS DocTools Holidays Contacts Akonadi 
IdentityManagement Activities)
 ??if (Gpgmepp_FOUND)
 ???? list(APPEND OPT_KF5_COMPONENTS Gpgmepp)

@@ -84,22 +84,19 @@ if (NOT LibAlkimia5_FOUND)
 ???? endif()
 ???? find_package(LibAlkimia5 7.0 REQUIRED)
 ??# Recent changes to LibAlkimia should allow us to remove this construct
 ??#?? include_directories(${GMP_INCLUDE_DIR})

-find_package(KChart 2.6.0)
+find_package(KChart 2.6.0 REQUIRED)

+?? add_definitions(-DGpgmepp_FOUND)

-cmake_dependent_option(ENABLE_GPG "Enable GPG support." ON
-???????????????????????????????????????????? "GPG_FOUND" OFF)
-add_feature_info("Encryption" ENABLE_GPG "Allows to store your 
financial data using strong GPG encryption.")
+add_feature_info("Encryption" GPG_ENCRYPTION "It allows encrypting your 
financial data.")

@@ -147,45 +144,38 @@ get_filename_component(QT_DIR???????? ${QT_B
 ???? "Qt install prefix defaults to the Qt prefix: ${QT_DIR}")

-cmake_dependent_option(ENABLE_ADDRESSBOOK "Enable addressbook support." ON
- "KF5IdentityManagement_FOUND;KF5Akonadi_FOUND;KF5Contacts_FOUND" OFF)
-add_feature_info("Address book" ENABLE_ADDRESSBOOK "Allows fetching 
payee information from KDE PIM system.")
-cmake_dependent_option(ENABLE_HOLIDAYS "Enable addressbook support." ON
-???????????????????????????????????????????? "KF5Holidays_FOUND" OFF)
-add_feature_info("Holidays" ENABLE_HOLIDAYS "Allows fetching holidays 
from KDE PIM system.")
+if(KF5IdentityManagement_FOUND AND KF5Akonadi_FOUND AND KF5Contacts_FOUND)

-cmake_dependent_option(ENABLE_ACTIVITIES "Enable activities support." ON
-???????????????????????????????????????????? "KF5Activities_FOUND" OFF)
+add_feature_info("Address book" KMM_ADDRESSBOOK_FOUND "It allows 
fetching payee information from KDE PIM system.")
+add_feature_info("Holidays" KF5Holidays_FOUND "It allows fetching 
holidays from KDE PIM system.")

 ??option(ENABLE_FORECASTVIEW "Enable forecast view" ON)
-add_feature_info("Forecast view" ENABLE_FORECASTVIEW "Adds possibility 
to calculate forecasts.")
-cmake_dependent_option(ENABLE_REPORTSVIEW "Enable reports view." ON
-???????????????????????????????????????????? "KChart_FOUND" OFF)
-add_feature_info("Reports view" ENABLE_REPORTSVIEW "Adds possibility to 
display chart and table reports.")
+add_feature_info("Forecast view" ENABLE_FORECASTVIEW "It adds 
possibility to calculate forecasts.")
+option(ENABLE_REPORTSVIEW "Enable reports view" ON)
+add_feature_info("Reports view" ENABLE_REPORTSVIEW "It adds possibility 
to display chart and table reports.")
 ??option(ENABLE_BUDGETVIEW "Enable budget view" ON)
-add_feature_info("Budget view" ENABLE_BUDGETVIEW "Adds possibility to 
plan a budget.")
+add_feature_info("Budget view" ENABLE_BUDGETVIEW "It adds possibility 
to plan a budget.")
 ??option(ENABLE_ONLINEJOBOUTBOXVIEW "Enable online job outbox view" ON)
-add_feature_info("Online job outbox view" ENABLE_ONLINEJOBOUTBOXVIEW 
"Adds outbox for sending online jobs.")
+add_feature_info("Online job outbox view" ENABLE_ONLINEJOBOUTBOXVIEW 
"It adds outbox for sending online jobs.")

 ??cmake_dependent_option(ENABLE_SQLSTORAGE "Enable SQL storage support." ON
 ?????????????????????????????????????????????? "Qt5Sql_FOUND" OFF)

-add_feature_info("SQL Storage" ENABLE_SQLSTORAGE "Allows storing your 
financial data in SQL database.")
+add_feature_info("SQL Storage" ENABLE_SQLSTORAGE "It allows storing 
your financial data in SQL database.")

 ??cmake_dependent_option(ENABLE_SQLCIPHER "Enable SQLCipher support." ON
 ?????????????????????????????????????????????? "SQLCIPHER_FOUND" OFF)

 ??# Otherwise compilers halt on something like that:
 ??# ld: library not found for -lsqlcipher
-# on MS Windows, FreeBSD, macOS, and Ubuntu 14.04 (Ubuntu has CMake 
3.5.1 but I'm not sure if it's the one to blame).
+# on MS Windows, FreeBSD, and macOS.
 ???? link_directories(${SQLCIPHER_LIBRARY_DIRS})

-add_feature_info("SQLCipher" ENABLE_SQLCIPHER "Allows encrypting your 
SQLite3 database.")
+add_feature_info("SQLCipher" ENABLE_SQLCIPHER "It allows encrypting 
your SQLite3 database.")

 ??cmake_dependent_option(ENABLE_IBANBICDATA "Enable IBAN/BIC data 
support." OFF
 ?????????????????????????????????????????????? "Qt5Sql_FOUND" OFF)
@@ -228,7 +218,7 @@ else()

-add_feature_info("OFX Importer" ENABLE_OFXIMPORTER "Allows importing 
OFX files (have client uid version: ${nice_LIBOFX_HAVE_CLIENTUID})" )
+add_feature_info("OFX Importer" ENABLE_OFXIMPORTER "It allows importing 
OFX files (have client uid version: ${nice_LIBOFX_HAVE_CLIENTUID})" )

 ??# check for optional KBanking support
 ??find_package(AQBANKING 5.6.5)
@@ -271,21 +261,18 @@ add_feature_info(iCalendar ENABLE_LIBICA

 ??option(ENABLE_QIFIMPORTER "Enable QIF Importer" ON)
 ??option(ENABLE_QIFEXPORTER "Enable QIF Exporter" ON)
-add_feature_info("QIF Importer" ENABLE_QIFIMPORTER "Allows importing 
QIF files.")
-add_feature_info("QIF Exporter" ENABLE_QIFEXPORTER "Allows exporting 
QIF files.")
+add_feature_info("QIF Importer" ENABLE_QIFIMPORTER "It allows importing 
QIF files.")
+add_feature_info("QIF Exporter" ENABLE_QIFEXPORTER "It allows exporting 
QIF files.")

 ??option(ENABLE_GNCIMPORTER "Enable GNC Importer" ON)
-add_feature_info("GNC Importer" ENABLE_GNCIMPORTER "Allows importing 
GNUCash files.")
+add_feature_info("GNC Importer" ENABLE_GNCIMPORTER "It allows importing 
GNUCash files.")

 ??option(ENABLE_CSVIMPORTER "Enable CSV Importer" ON)
 ??option(ENABLE_CSVEXPORTER "Enable CSV Exporter" ON)
-add_feature_info("CSV Importer" ENABLE_CSVIMPORTER "Allows importing 
CSV files.")
-add_feature_info("CSV Exporter" ENABLE_CSVEXPORTER "Allows exporting 
CSV files.")
+add_feature_info("CSV Importer" ENABLE_CSVIMPORTER "It allows importing 
CSV files.")
+add_feature_info("CSV Exporter" ENABLE_CSVEXPORTER "It allows exporting 
CSV files.")

 ??option(ENABLE_UNFINISHEDFEATURES "For devs only" OFF)
-add_feature_info("New features" ENABLE_CSVEXPORTER "Compiles unfinished 
features for testing.")
-add_feature_info("" KDE_INSTALL_PREFIX_SCRIPT "create script to support local execution")

 ??# TODO: this should be removed



 ???? Pressure creates diamond.

On 2019-07-11 1:32 p.m., Jack wrote:
> 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.
> Jack
> 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
>>> -------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KMyMoney-devel mailing list