Removal of the master Branch

[LeStarch]

Our F´ master branch only updates when being released. As such, it acts (effectively) as a pointer to the latest release and has no other substantial effect on the over all project.

This has several substantial downsides:

1. Maintaining a linear history on master that lags behind devel is impossible without push --force as Github always rewrites commits when rebase merging
2. master requires many locks to prevent commits from being merged there instead of devel
3. master reruns all CI checks during a release to ensure that the working devel branch works when effectively renamed master. Note: this is testing the exact same HASH

I have yet to determine any upsides to maintaining master.

The recommendation is to remove the master branch. We'd merge to devel, and tag releases off from devel. Users wishing stability should still (as today) use a tag. Developers should develop off devel.

There is one downside identified from this recommendation: as we approach a release, some PRs will not be merged until after the release. This takes place with the master branch already, and would continue to be the case.

[astroesteban]

This sounds a lot like trunk-based development. We recently switched some of our internal projects to this approach. We had the same problem where our main would just reproduce the same pipeline as devel. So now we just commit to main and create tags and release/{version} branches. It's worked really well for us and increased our development velocity. This also forced us to add more robust and rigorous approval testing.

I like this change 👍

[LeStarch]

This is how we do fprime-tools and fprime-gds development too. It works well there.

[SterlingPeet]

Hmm, we’ve used master/main as branch that only contains release commits (good reference points) and that has worked but does have a somewhat complicated workflow. In this scenario, devel and main diverge at the first commit in history, and each commit of main is all of the squashed commits on devel between those points in time. The upside is that you can’t checkout a commit on the main branch that doesn’t correspond to a release tag.

I don’t advocate for that paradigm with this project, but I did think it was worth noting.

I’m a little confused by the “always re-writes” part, because there should be settings that can be used specifically for doing a PR with fast-forward merge within GitHub. OTOH, if thats not working for you, then I definitely side with the sentiment that linear history should not be the difficult path, and adjustments should be made.

Around 5 to 10 years ago, there was a general sentiment that software from github gets pulled down from whatever the default branch is and installed on the local box, often times without even considering whether the OS had a packaged version of this same software. I don’t think this fad has persisted, but it did drive a lot of projects to be more conservative about their default branch in order to reduce the number of rando issues coming in on their bleeding edge development branch.

As I reason through it, I don’t think F Prime suffers from the social problems, the users fall in a category that is more likely to sort out the difference between tags and development branch.

It does bring up the README as a concern though, it needs to be appropriately descriptive with respect to the latest release branch(es), and not develop. That might make updating it more challenging, or necessitate being much more careful about what it contains at all points during the development.

[LeStarch]

Good points @SterlingPeet!

This issue comes in from the Github UI. To merge the PR from devel to master we have 4 options:

1. "Merge": creates a merge commit that is not in devel. This breaks our desire to maintain a linear history
2. "Rebase": rebase should be the right choice, however; according to the Github docs "GitHub will always update the committer information and create new commit SHAs". Thus rebasing will change SHAs and devel will not match master
3. "Squash": right-out if our goal is to keep devel and master with a unified history
4. Fix it by hand: we can fix things by hand using rebase or fast-forward using the git command line. This fixed history can be pushed to master. However, this is extra work not necessarily worth the effort.

[SterlingPeet]

Hmm, it seems like a rather significant oversight to not be able to do that. I am feeling that I have a hole in my experience here, which is probably because most projects that I own don't have enough contributors to truly warrant locking down the repo permissions this heavily.

[LeStarch]

I confirmed here that it is not possible. https://stackoverflow.com/questions/60597400/how-to-do-a-fast-forward-merge-on-github

While you could do this via the command line (or GH Action) we've not seen compelling reason to keep master with the added work.

[LeStarch]

We will remove the master branch!