Branching/Release scheme

[opatut]

Hello there. I use this issue to describe the current branching scheme.

I'd like to have it this way:

• master is development branch where most of the stuff is submitted to
• stable is current stable release
• hotfix is cherry-picks branches from the current stable for minor fixes that do not break things, mostly security fixes. This is also merged into master continuously.
• a release-{ver} branch to cherry-pick release commits for review before tagging a release
• feature/{description} branches for unfinished features and rewrites -- may be rebased onto master before submitting a PR. All feature branches must only be merged with a PR.

However, I am not working organized enough to always stick to this pattern. I am sorry for that, hope I can change it. So what I sometimes do is macro commits with huge, stuff-breaking changes, just because I refactor lots of code while adding some features. I know, that's bad, I should not do it. Still, it happens from time to time (which is why my current checkout looks the way it does 😒).

I hope I can fix it. Maybe I'll release 2.1.0 soon, and move a bunch of features (issues) to 2.2.0. Maybe I cherry-pick some security commits into a 2.0.1 patch release. What's your preference?

I have fixed the history and force pushed. Now we'll stick to above pattern.

[Akasch]

I think this sounds good.

You should make a 2.0.1 if the 2.1.0 will not released soon I think, you could take b837309 and add #70. Together the Security Patches from @picobyte are in and the copy is not broken anymore

[opatut]

I am currently cherry-picking all commits since 2.0.0 onto above branches locally. When I'm done I'll release 2.0.1 and force push to clean up this mess. Please stay tuned here.

[RalfJung]

Why do you want to have both a "stable" and a "hotfix" branch? That sounds pretty redundant to me, and hence unnecessary work. I would probably have fewer branches, something like

• master with current development
• stable-{x.y} with the branch for all versions "x.y.z"

plus tags in the stable branches for releases.
I would track the latest stable branch on my server. A patch (security) release would happen by cherry-picking the commits from master to the respective stable branch (or maybe developing them on stable and merging to master?), giving it some testing, and tagging. A major release would happen by creating a new stable branch, and stabilizing/reviewing there until everybody is happy.

This is not to say that I claim this is the best or even a reasonable model ;-) . I'd just be curious to learn why you decided for the plan you described above.

[opatut]

Basically, what you describe as stable-{x.y} branches are my release-{x.y.z} branches, and stable is just the "current release". So people can just check that out and always have the current release running. It's more like a recommended version for your server.

The hotfix always branches from stable, so if you want to have the latest running version with unreleased security patches or very minor bugfixes, you check that out. I don't want to do patch releases all the time.

[RalfJung]

Basically, what you describe as stable-{x.y} branches are my release-{x.y.z} branches, and stable is just the "current release". So people can just check that out and always have the current release running. It's more like a recommended version for your server.

I see. There is one usability difference though: When I track stable, I have to be careful about migrations when you change that branch from x.y.z to x.(y+1).0. When I track release-x.y.z, I won't even notice release-x.y.(z+1). Whereas, if there was release-x.y, then I could track that pretty much automatically without having to worry.

(This is assuming that migrations will never happen in a patch release.)