General questions about repository

[ds1709]

I'm trying to understand the structure of repository (branches and tags). Sorry, but it looks like some sort of "chaos". Analyzing existing commit tree, I have a few questions:

• Is it TBD strategy? If so, it must be release on each fix. If it "Git flow", why there's no "develop" branch?
• Why when you release a new version ("Bump version"), you don't return this changes back into source branch? It's confusing when consider which branch to use for development. E.g., there two branches, release/11.0 and release release/11.0.10, and one branch remotes/avalonia/customers/chaos-11.0. It seems like someone created branch from wrong source branch. Usually, if you a planning to support old version (e.g., security fixes), you creates support branches, in case with version 11.0 it will be called support/11.0 or lts/11.0.
• There are many branches, that seems like dead. What are you planning to do with them? Some branches was created about ten years ago.
• Release 11.0.10 was at 05.03.2024. After that there was many improvements in branch release/11.0 (that actually must be called support/11.0). Is it planned to release this improvements as 11.0.11 or they are already released? Or is this branch dead? If I want to make some fixes in version 11.0, must I branch from commit before release/11.0.10 or from release/11.0?
• Is there any information about submodules exact commits, used on releases? I was trying to build version 11.0.10, but submodules by default updates on HEAD. So I had to manualy find submodules commits, compatible with version 11.0.10.

Currently repository looks "dirty", and it must be cleaned and reorganized. Maybe even commit tree must be rewriten with git-filter-tree util. I think, It's hard to navigate in it and hard to work with it, both for repo owners and contributors.

Some additional info:
When release in git flow, it assume that you creates temp release branch, "bump version" in it, merge it into master, and ALSO merge it back into develop (or merge master back into develop after release). Then you tag master branch with version, not release branch. After all release branch is deleted.

In TBD strategy, when you have only master branch, you create release branch, "bump version" in it, merge it back into master and tag master after merge. Or you have one release branch (or one for each major version) and merge master into it when release, and tag release branch.

There must not be "twigs" with version tags.

[jp2masa]

I'm definitely not an authority on this, but I understand it as follows:

• Is it TBD strategy? If so, it must be release on each fix. If it "Git flow", why there's no "develop" branch?

It's similar to TBD: master is the trunk, and all fixes that should be backported are cherry-picked to the appropriate release (support) branches. However, each release includes multiple fixes.

• Why when you release a new version ("Bump version"), you don't return this changes back into source branch? It's confusing when consider which branch to use for development. E.g., there two branches, release/11.0 and release release/11.0.10, and one branch remotes/avalonia/customers/chaos-11.0. It seems like someone created branch from wrong source branch. Usually, if you a planning to support old version (e.g., security fixes), you creates support branches, in case with version 11.0 it will be called support/11.0 or lts/11.0.

As explained in the previous point, changes are cherry-picked from master to release (support) branches. Also, calling it support/11.0 or lts/11.0 is just a convention, here they are called release/11.0.

• There are many branches, that seems like dead. What are you planning to do with them? Some branches was created about ten years ago.

They probably should be deleted, but it's not a priority.

• Release 11.0.10 was at 05.03.2024. After that there was many improvements in branch release/11.0 (that actually must be called support/11.0). Is it planned to release this improvements as 11.0.11 or they are already released? Or is this branch dead? If I want to make some fixes in version 11.0, must I branch from commit before release/11.0.10 or from release/11.0?

They will probably be released as 11.0.11. To make some fixes, they should be first done on master and, if approved, they can be backported to 11.0.

• Is there any information about submodules exact commits, used on releases? I was trying to build version 11.0.10, but submodules by default updates on HEAD. So I had to manualy find submodules commits, compatible with version 11.0.10.

I think that git tracks each submodule's commit hash in the index (SO reference)? I rarely use submodules though.

[ds1709]

calling it support/11.0 or lts/11.0 is just a convention

Yes, but it's better to folow common naming conventions. Naming support branches as release is missleading. Also it "lost" among real release branches.

And what about merging version bumps back in master/support branch? What tool your team using to visualise commit tree?
Our team uses TortoiseGit revision graph, and when release branches don't merges back in master, it looks bad.
Here is a fragment of this repository tree:

It's veeeeery hard to navigate in it, every release shows here like a "twig".
And this how it looks for tags only:

When you merge release branches back, your history graph looks linear, but when you dont, it's becom a "hedgehog".
There are a nice tool git filter-repo, which can be used to rewrite history and make it much preaty.
If your team would like to do this, but has no resources, I can rewrite tree by my own and provide you result as another git repo.

[Gillibald]

Multiple fixes are only valid for a specific release branch so it does not make sense to merge those fixes back into the master

[ds1709]

It's true only for major or minor versions (if you follows SemVer principles, and you do coz you publish nuget packages). But in this case you have support branches, which are master-branches for a specific version.
E.g., there'is a bug #15990. Assumes version 11.1.0 is released. This bug presents in master and release/11.0. So, in perfect, I create fix branch from master, fix it, release vesion 11.1.1, and then merge it back in master. After that, I create new fix branch from release/11.0, fix this bug there (cherry-pick), release version 11.0.(+1), and merge release branch back into release/11.0. No conflicts, all works as should.
Fixing bugs in patch (third version number) is conceptually imposible. If you released version 11.0.10, you cant fix bug in version 11.0.9. You will fix it in release/11.0 and release this fix in version 11.0.11.

[maxkatz6]

E.g., there'is a bug #15990

As a contributor, all you need is to fix it in the master.
Backporting is done by the maintainers and is automatic (we use labels) by cherry-picking from master to the release/11.0. And next release/11.0.11 is created when needed.

We are completing work on 11.1 right now. And master is already identified as 11.2version (for alpha builds on nightly feeds).

[ds1709]

My take was about branching and merging back to master/support when release (concerns Why when you release a new version ("Bump version"), you don't return this changes back into source branch? question) . Versions 11.0 and 11.1 was just an example of scenario when you fix bug in master and support branches.

[maxkatz6]

There could be lots of subjective naming, but essentially flow looks like this:

1. "master" branch is basically a development branch. All new fixes and features first go there.
2. On each commit we create a build that can be used from nightly (only master) and all (includes PRs) nuget feeds.
3. "release/11.0" is a branch where we backport all fixes that we want to include in the next patch release.
4. "release/11.0.11" is a specific next patch release that will be branched out from the "release/11.0", when it's ready.

All the "stable/" and "customers/" and other branches are artifacts of the past.
Cleaning up dead branches would be nice, but on practice it's quite problematic.

[ds1709]

Yes, I understood that. My take was just about merging release branches (real release branches, not support branches) back into master/support branch after release.

Cleaning up dead branches would be nice, but on practice it's quite problematic.

It can be yeasily done at least for branches, which was merged into master. They are clearly visible In revision tree, and can be deleted without any risk of losing anything.

[thevortexcloud]

You do risk losing the ability to build old versions from source easily if branches get removed.

[ds1709]

@thevortexcloud all old version are tagged, so you will not lose it.

[ds1709]

By the way, branches like "release/X.Y.Z" 100% can be deleted, because they have tags at same commit.