lemmy
lemmy copied to clipboard
LemmyNet
Question: What is the purpose/meaning/workflow of the `release/v0.18` branch?
Question
- It appears to be existing since version
0.18.1which has been tagged inmain - Version
0.18.2has been tagged in branchrelease/v0.18 -
RELEASES.mdinmainhas been updated to version0.18.1 -
RELEASES.mdinrelease/v0.18is still at version0.17.2 -
releases/v0.18is 7 commits ahead ofmainmost of which have matching commits inmain(just with different hashes). Are these independant commits or does it look like this, if they have been merged frommaintorelease/v0.18or vice versa, too? - Is
releases/v0.18just a temporary branch which essentially died when version0.18.2got released or is it meant to stay and tag all version0.18.xreleases?
I'm confused.
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
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
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.
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
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.
Thank you for answering. If anyone is able to describe in human language what they see as significant differences between main and 0.18.3 release, please share. Have a good weekend. It's been a fascinating journey to see issue #2910 be addressed.
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).
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.
ok, so does woodpecker run testing on this other branch too? Is it a best practice for developers to test against main and the /v0.18 release branches, because upgrade behavior...