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 (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 <t...@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
-------------------------------------------------------------
