Mastodon: Git Branching Strategy Change / Proposal

[ErdMutter92]

I was wondering if it would be possible to adjust the branching strategy used for development of Mastodon. In the current state master is a pool of chaos and not a trusted source for a stable production build.

I propose something along the lines of feature branches being cut from a develop branch, which contains everything in master. Master remains the most stable and up to date release of the platform. Keeping tags to denote SHAs of past and present releases. Then when a new release happens you tag and put a merge into master from develop. Merge / Pull requests for master would only be from develop or when there is a bug in production. If it is for a bug in production (master) then you back merge master into develop.

For the people who wish to set up automatic push-button deployments for updates they could do so knowing that master is 'relatively' stable. In theory with a setup like that one could have tests automatically run when master gets updated, and if passed start a build. Upon a successful build from docker-compose it would then deploy.

Additionally you could then add a beta (staging) branch for when you want to have people test out new changes, but need feedback before it goes into stable (release).

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• [N/A] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[wxcafe]

This sounds like a thing we want to implement to have a better development workflow

also I'd like to suggest we adopt the old terminology of SVN and call the one of the branches 'trunk'

[nightpool]

Adopting such an antiquated development model doesn't seem very useful to me—the people who need things from master would still try to get them from develop, and the ones who use tagged releases would still be stuck behind.

I would rather we adopt similar policies to what, e.g., Rust does—master is relatively unstable, but we increase the amount of testing done on pull-requests before we merge them (make sure someone can run the code, for example, or doing more thorough reviews, or requiring tests for new features). Currently master isn't even gated on status checks, which seems really bad to me.

To allow small changes to pass while large ones can still get merged, we can use a "rollup" strategy where many small pull requests that don't have a high probability of failure are made into one large pull-request and tested that way.

[ErdMutter92]

@nightpool The idea behind the development model I mentioned is to create development channels and provide stability to the people looking to have single button deployment (or just build off master). Going with an unstable master and dumping the lot into it would defeat that purpose, and provides confusion to people who are already cloning master to deploy.

I agree you will still have people cherry picking things from develop or deploying straight from develop but those people would need to know its inherently unstable (and that master is a more stable option), but it would still provide them with the ability to do easier deployments.

Another possibility would be to have a stable branch, that lives along side master that points to the most recent release tag. Both are virtually the same thing thought... you are just calling develop master, and master stable.

Edit: Forgot to mention that I strongly agree with running the tests before merging in a feature branch. It should be a standard step in the code reviewing process.

[mjankowski]

I was wondering if it would be possible to adjust the branching strategy used for development of Mastodon. In the current state master is a pool of chaos and not a trusted source for a stable production build.

What problem are you trying to solve? The current advice is to use tagged releases for running instances, and not run from master.

[ErdMutter92]

@mjankowksi to allow for different stages of testing to happen for releases, and to allow for a stable branch that people can just git pull, build, and deploy.

[ProgVal]

@ErdMutter92 updates sometimes require manual changes, like adding a sidekiq queue to the systemd unit.
Any automatic update process will miss these changes.

[wxcafe]

yeah, automatic updates are not a thing you can usually have on a hosted service, and it's definitely not a thing you can have on a hosted service such as this one, with multiple ways to deploy it (docker, systemd, init, ...)

[ashfurrow]

So I've been thinking about this, and I think the following could make sense:

• Use a new develop branch for developing.
• Use master to hold the latest release.
• Set develop to be the "default" git branch (in GitHub config). This will be checked out when people clone for development purposes and be used for PRs.
• Point the Heroku Button / Scalingo config to the master branch.

Then maybe admins will stop running off of master, and we'd see a lot fewer issues opened with problems. Thoughts?

[petersmithca]

The only issue that I may see with @ashfurrow note is that (and I could be mistaken), the default is what any "zip file puller/read instructions cloner" is going to get. I'm betting many admins don't know git, and won't know (or care to) switch branches.

Slightly more work for devs maybe, but keeping master as default, but also only holding tagged releases might be better. Devs would/should know how to switch branches to develop before doing work or making a new branch.

That said this is just my experience from other projects. I don't intend to contribute here (mainly because I detest Ruby, but that's personal preference)

[ashfurrow]

Many contributors are new to GitHub too, though I suppose we could always change which base branch a PR is using. Yeah, I'm fine either way. But we need a develop branch for sure.

[ProgVal]

@ashfurrow That's equivalent to having a default master branch, and having a released branch pointing on the last release.

[ashfurrow]

Maybe we should take this discussion to a Skype call or something? It's high priority so I'd like to figure something out sooner rather than later.

[wxcafe]

Up? It seems to me that having a stable branch that's always at the last release, a master that's tested but not on a specific release and a dev branch that's not specifically tested would be nice (kinda like how *BSDs have -RELEASE (stable), -STABLE (master) and -CURRENT (dev))

[wakingrufus]

I am not a contributor, but as a software developer, I'd just like to add my 2 cents. Stick to what you have. If someone wants to be able to just git pull the latest stable, they can use something like git describe --abbrev=0 --tags
The old school gitflow w/ develop branch will over complicate things, especially with hotfixes in the mix, causing conflicts between master and develop. I agree with the ideas from @nightpool

[Gargron]

I think this can be closed. Tags are stable releases so if you want to update automatically, you can check out the latest tag. Master is "development" but nobody can commit directly to master, everything goes through feature branches and PRs with required tests and reviews.