Vega-strike-engine-source: Branching Strategy and where work gets done...

[BenjamenMeyer]

Pointed in #47 (https://github.com/vegastrike/Vega-Strike-Engine-Source/pull/47#issuecomment-610031798) and #45 there seems to be a discrepancy on where code changes should go, or what the branching strategy should be. I don't know what the history was under Subversion so raising this here so we can all be clear going forward on how to work on it.

There are a few options that are the norm:

1. Work on Master, release creates a branch, changes continue to master, releases get updates as needed. Master is authoritative.
2. Work is done on branches; Master gets occasional updates when getting ready to build the next release branch.

[BenjamenMeyer]

I don't know how it was done in the past. I propose following option 1 and using a Master is Pristine strategy:

1. Master branch is protected; only things that pass the PR gates (travis-ci right now) get into master.
2. Master is clean and can be released at most any time.
3. Releases create a branch for which bug fixes for the release go.
4. Primary development is on Master.

NOTE: I say "most any time" for number 2 because some times you may have to go through a few PRs to get to a good release state; but master should be clean and pass all gates as the norm.

[royfalk]

I agree. This is how we do it at my work too.
It seems to be the standard.
Not sure what you mean by 4. Did you mean development is always done in a feature branch. Master only receives merges after PR?

From: Benjamen Meyer [e-mail]
Reply-To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Date: Tuesday, 7 April 2020 at 0:58
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Roy Falk [e-mail], Assign [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Branching Strategy and where work gets done... (#48)

I don't know how it was done in the past. I propose following option 1 and using a Master is Pristine strategy:

1. Master branch is protected; only things that pass the PR gates (travis-ci right now) get into master.
2. Master is clean and can be released at most any time.
3. Releases create a branch for which bug fixes for the release go.
4. Primary development is on Master.

NOTE: I say "most any time" for number 2 because some times you may have to go through a few PRs to get to a good release state; but master should be clean and pass all gates as the norm.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/48#issuecomment-610059003, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEFHOCXXHGFKYJNYP63RLJGB7ANCNFSM4MCUBBSA.

[BenjamenMeyer]

Sounds like we have agreement on this. I'll add verify branch protection on this repo since we have Travis-CI on it. We'll address other repos as work starts happening on them.

[BenjamenMeyer]

admins can get around the rules when necessary at least for now; long term we may want to tighten that up, but where we are right now I think that's required.

Master is protected.
Do we want to have rules for release branches to?

[BenjamenMeyer]

I applied the protections on master to 0.5.* branches too.

[BenjamenMeyer]

@vegastrike/core-reviewers if we 're going to go with the branch strategy I proposed in https://github.com/vegastrike/Vega-Strike-Engine-Source/issues/48#issuecomment-610059003 then I think we need to roll back any changes to the 0.5.3 branch to when it was released; it should only get changes specifically designated for 0.5.3 and changes should only go to master right now.

Thoughts?

[stephengtuggy]

admins can get around the rules when necessary at least for now; long term we may want to tighten that up, but where we are right now I think that's required.

Master is protected.
Do we want to have rules for release branches to?

I vote yes: rules for release branches too.

[stephengtuggy]

The "Master is Pristine" strategy sounds good to me. At my last job, we typically used something very similar to your proposal, @BenjamenMeyer , but with the addition of a development branch as sort of a staggered master branch. We would typically get work done on feature branches etc. Usually only one or two contributors working on a particular feature branch at a time. Then these feature branches would get merged back into development via pull requests. (After passing code reviews, CI, etc.) development always has the latest changes that have been accepted by the community/team. master is updated when possible, but most often only when preparing for a release.

In other words, something along the lines of git-flow, I guess? But adapted slightly.

Furthermore: release branches will probably continue to be needed for the foreseeable future. However, I think eventually, we _might_ want to consider moving away from those. Use tags/GH releases, rather than branches. But that is open for discussion.

And to echo what @pyramid3d , @BenjamenMeyer and others have said: too much rigidity in rules can end up being an obstacle. Finally learning that myself here recently. :-) Whatever we decide on should probably be considered more guidelines than hard-and-fast "rules." :sunglasses:

What do you guys think?

[BenjamenMeyer]

@stephengtuggy generally yes. I generally use a Forking strategy as opposed to a Feature Branch strategy; but otherwise very similar. Haven't used git-flow myself. Whether we need a branch other than master or the current release branch, will greatly depend on how fast we move as a community.

The Qt community has a very fast development pace, so the every day devs use a dev branch; community members generally contribute to a stable-dev branch; and then that gets pushed to a release branch where releases are cut from, with each release having its own branch for maintenance. We're a long way from that so I don't think we need that kind of structure.

Whether we'll need a release branch in the future will largely depend on how the community that uses the VegaStrike engine works with locking to specific versions. If we can get things setup in a way that's easy for them to upgrade, then we'll likely be able to move to just using Tagged release. Otherwise, we'll have to maintain a release branch as I described above to help support them. So much depends on how the community forms/grows.

Note: Not trying to limit anything - just inform right now.

[stephengtuggy]

@BenjamenMeyer Sounds good to me.

[BenjamenMeyer]

Based on conversation and observation of practice I think we've come to agreement on this. It'll have to be written up in the contributor guidelines (see #27), but we can close this.