Question: What is the purpose/meaning/workflow of the release/v0.18 branch?

[necropola]

Question

• It appears to be existing since version 0.18.1 which has been tagged in main
• Version 0.18.2 has been tagged in branch release/v0.18
• RELEASES.md in main has been updated to version 0.18.1
• RELEASES.md in release/v0.18 is still at version 0.17.2
• releases/v0.18 is 7 commits ahead of main most of which have matching commits in main (just with different hashes). Are these independant commits or does it look like this, if they have been merged from main to release/v0.18 or vice versa, too?
• Is releases/v0.18 just a temporary branch which essentially died when version 0.18.2 got released or is it meant to stay and tag all version 0.18.x releases?

I'm confused.

[alexandrupero]

I'm also confused by this, the difference is bigger now:

This branch is 32 commits ahead of, 46 commits behind main.

did main and the v0.18 branch diverge and meant to stay that way, or why is it not merged back? Hard to tell which branch to keep track of

[necropola]

It looks like the same changes are independently being applied to both branches (main and releases/v0.18) instead of being merged from one branch to the other.

[alexandrupero]

https://github.com/LemmyNet/lemmy/blob/main/Cargo.toml still has everything tagged as 0.18.1 - even though we are well past 0.18.2 - and I am building from source code to test the latest updates - and my server is identifying itself as a variation of 0.18.1

The cargo package versions seem to be lagging way behind indeed (are the commits updating them not applied?). But the reason your server is identifying itself as 0.18.1 is probably that the latest tag in the main branch is 0.18.1-rc.10 and the version is set by the latest tag in the branch (+ commit hash) in the dockerfile - and while the latest commits seem to have been applied, the tags are missing

[necropola]

That was to be expected, since it was done similarly with the 0.17.x (and earlier) releases. What I still don't get is, why main and the current release branch release/v0.18 appear to be diverging although they are actually not.

@dessalines Can you shed some light on what the branch strategy is for this project or rather point us to some documentation? Thanks.

[dessalines]

We use stable mainline on all our repos.

[necropola]

Then it seems that I do not understand stable mainline, i. e. I would expect to only see tiny release specific fixes in the release branch and a few cherry-picked fixes which also go into main., since the goal of the release branch is to freeze the code before releasing it.

But what I'm seeing is a release branch and main branch running concurrently for quite some time wiith both getting pretty much all changes applied (independently from each other).

[dessalines]

I would expect to only see tiny release specific fixes in the release branch and a few cherry-picked fixes which also go into main., since the goal of the release branch is to freeze the code before releasing it.

That is exactly what's in the release branch, cherry picked fixes from main, with no breaking changes.

main has a lot of breaking changes not in the release branch. Use a git command to compare the commits.

[dessalines]

CI will run for any pushes to other branches, or PRs to any branch.