[Lazarus] will fixes_2_2 be merged to trunk before next release?

[Martin Frb]

Note:
- My below reply only answers part to the general workflow in git. (e.g. 
how we merge and release, etc).
- I am not working on the QT related parts of Lazarus. Therefore I can 
not give any answers on the specific plans for QT.

On 22/03/2022 12:09, John Landmesser via lazarus wrote:
> Am 22.03.22 um 01:52 schrieb Martin Frb via lazarus:
>> Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:
>>> I would like to know if the fixes for lazarus 2.2 will be merged to
>>> trunk before next release? 
>> I don't know much about that particular issue, but from what I read:
>> There are no fixes in 2.2 that could be merged.
>
> Your answer would fit to the answer  Alexey Torgashin gave me to my
> question with title
> "[Lazarus] IDE qt5 compile error" from  14.03.2022 18;15

Ok, that was a different mail thread, which I hadn't seen/read.

> I am thinking about which is the base for next lazarus release if
> fixes_2_2 is NOT merged back to main development branch.

- "next release" => "next major release" = "2.4" (NOT: "next (minor) 
release" = "2.2.2")
- The base for Lazarus 2.4 will be whatever is in the current git "main" 
branch.

**AFAIK** (with regards to this QT issue) => As I said:
=> "fixes_2_2" does not contain anything that can be merged to fix your 
issue.
-  Something new (like a new feature) was added to "main" (aka trunk)
-  It was never added to "fixes_2_2"

So "fixes_2_2" does not have anything to "fix" your issue.
Rather "fixes_2_2" does not have the feature that doesn't work for you.

If you can't install (build yourself) the dependencies for that new 
feature, then your options are:
- wait for the dependencies to become available (as installable package 
/ as part of some installer)
- use "fixes_2_2"
- use "main", but revert (undo) the changes (aka: "the addition of the 
feature")
    => of course, over time that means to also revert/undo any 
change/addition that requires the new code....


On 21/03/2022 11:49, John Landmesser via lazarus wrote:
> I would like to know if the fixes for lazarus 2.2 will be merged to
> trunk before next release?
>
> And yes: i have a very poor knowledge about release models with git :-(

For the "release model", we use git (i.e., branches in git) exactly as 
we used branches in svn before.

- In SVN we had "trunk"       => Now, in GIT we have "main"
- In SVN we had "fixes_*_*" => Now, in GIT we have "fixes_*_*"

The only changes between how we use branches in GIT vs SVN is
- increased use of "feature branches" (we did once or twice in SVN)
- use of "merge-request branches"
Neither affects release management.
That is any  "feature branches" or "merge-request branches" eventually 
become part of "main" (or sometimes part of "fixes_*_*").
Before that, they don't account towards any future release. But once 
they are part of "main" (or "fixes"), they are simply seen as part of 
that branch.

For future releases, we have the same branches as we had in svn.
Exactly as we used to do with SVN, we now do in GIT:
=> New code goes into "main".
  - "Feature":   If it is a feature, then it goes to "main" only.
        It may get further changes, fixes, even part-undo.... And it 
will go into the next major release.
        (In rare cases, features that are not ready when the next major 
release happens, can be undone in the next "fixes" branch (i.e. for 
"2.4" that would be "fixes_2_4" once that has been branched).
  - "Bug-Fix":   If it is a bug-fix, then it will/should be merged to 
the fixes-branch.
       That is if the bug exists in the current "fixes" branch....
=> Sometimes a bug only exists in "fixes":
   That is, something got broken in "fixes", but it was not broken in 
"main". Maybe a bug-fix that was merged had a side effect causing such a 
bug.
   Then the "code to fix this" will go directly into the "fixes" branch. 
And only there.
=> Sometimes an individual developer works in "reverse":
   That is, if there is a *bug* in "main" and in "fixes":
      - the developer adds his fix first in the "fixes" branch
      - then merges it to "main"
        (again, that actually also happened in SVN / IIRC, I haven't yet 
seen it happening in GIT)

**The issue you mentioned** belongs to (and only to):
"    => New code goes into "main".  "
"       - "Feature":    "

If you build your own IDE from a "cloned " git repo, then you can use 
"git revert" https://git-scm.com/docs/git-revert to undo any changes you 
don't want in your build.
- I do not know which commits that are
- you would need to learn more about git, if you want to keep updating 
after the revert....