Suggestion for AGM branching concept

bux commented 10 years ago

@KoffeinFlummi @commy2 @esteldunedain @CorruptedHeart

Here are some suggestions on how we could start to make better use of branches. My company is using a similar model to great success.

Add "develop" / "dev" branch as an integration branch for features
Features and Bugfixes (> 3 to 5 lines of code) happen in either a fork or their own feature branch they use "dev" as their parent.
Feature branches or pull requests are merged into the "develop" / "dev" branch
once "dev" is ready for release, fork a release branch. This is kind of a beta version. Meanwhile development can continue. If needed, bugfixes and release related stuff (docs, comments, versionnumbers) are merged into the release branch and dev branch
if the release branch is finshed it is merged into master and tagged (already done through githubs releases) and merged back into dev
master always contains the latest released version
if hotfixes for the release are needed (e.g. fixes for FFV) they get a seperate hotfix branch and get merged into master (master is then again tagged) and dev branch

The most prominent change compared to today's workflow would be working in dev branch instead of master. The other suggestions mostly happen before and during releases and are in there to be able to continue developing while releasing or maybe hotfixing a release.

I'd love hearing your thoughts about it.

KoffeinFlummi commented 10 years ago

I don't like the idea of only using master for the last release; That's what we have tags for. Should the need for a hotfix arise, you can checkout that tag and cherry-pick the relevant commits from master.

What I would like though is that there's no ugly debug shit on master (@commy2), and generally outsource new features to other branches.

nicolasbadano commented 10 years ago

I agree with Flummi. People tend to download master when going for the latest AGM stuff, so having the master=dev helps us in having more testers looking at newly added features.

Also, we tend to never backport fixes to previous releases and our release window (code freeze) is very short (just a couple of hours for flummi to pack everything and check everything's alright), so not being able to commit on that period is not a big deal.

What I would like though is that there's no ugly debug shit on master (@commy2), and generally outsource new features to other branches.

:+1:

Our job here is to keep gently pushing our star programmer into seeing the light about branches in general.

KoffeinFlummi commented 10 years ago

Our job here is to keep gently pushing our star programmer into seeing the light about branches in general.

Goddamnit. You just complimented him. He won't shut up about that for days...

nicolasbadano commented 10 years ago

Shh, I'm try to psychologically condition him by using the word branches on the same sentence

bux commented 10 years ago

Ok, ok :smile:

jonpas commented 10 years ago

Great ideas, but as GitHub works perfectly with AGM right now, there really isn't a point. But you know, ideas like this are always welcome, without evaluating them you never know.

commy2 commented 10 years ago

If this is so important to you, Flummi, then why do I see the scope adjustment UI regardless of what weapon or optic I use and get script error messages everytime I switch to the binocular SINCE 3 DAYS?

KoffeinFlummi commented 10 years ago

If this is so important to you, Flummi, then why do I see the scope adjustment UI regardless of what weapon or optic I use and get script error messages everytime I switch to the binocular SINCE 3 DAYS?

Well, first: for 3 days

Also, fixed. sorry.

KoffeinFlummi / AGM

Suggestion for AGM branching concept #1539