Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial documentation of focus feature system #3029

Merged
merged 4 commits into from
May 11, 2016
Merged

Add initial documentation of focus feature system #3029

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e70751e
Add initial explination of project goal system
kymckay Dec 13, 2015
d7ba566
Cleanup project goals documentation
kymckay May 11, 2016
03832ac
Merge branch 'gh-pages' into goalsDoc
kymckay May 11, 2016
ef834fb
Add description to Branching and Release
kymckay May 11, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 25 additions & 12 deletions wiki/development/branching-and-release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
layout: wiki
title: Branching and Release
description:
description:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing description

group: development
parent: wiki
order: 5
Expand All @@ -10,28 +10,41 @@ order: 5

## 1 Versioning

For ACE3 we use an versioning strategy based on <a href="http://semver.org/">Semver</a>. This means our version numbering is structured `MAJOR.MINOR.PATCH.BUILD`.
For ACE3 we use a versioning strategy based on <a href="http://semver.org/">Semver</a>. This means our version numbering is structured `MAJOR.MINOR.PATCH.BUILD`.

Because this modification is for Arma and backwards compatability is not always possible, our `MAJOR.MINOR.PATCH.BUILD` rules are slightly different. We increment the:
Because this modification is for Arma and backwards compatibility is not always possible, our `MAJOR.MINOR.PATCH.BUILD` rules are slightly different. We increment the:

MAJOR version when we switch to a new arma version (ie Arma 4 or standalone expansion),
MINOR version when we add new features or large amount of bug fixes.
PATCH version when a release only contains bug fixes.
MAJOR version when we switch to a new arma version (i.e. Arma 4 or standalone expansion).
MINOR version when a release contains significant changes or new features.
PATCH version when a release only contains fixes and enhancements.

## 2 Branching and releases
## 2 Project goals

We have a release scheduled every 2 weeks on a Tuesday. On the Friday before release, the project management will decide whether or not this scheduled release will continue. When continuing with the release, the current `master branch` will be merged into the `release branch`. The release branch will not contain any direct commits and no other branches will be merged into this branch. The exception being `hotfixes`, which are branched off `Release` and merged back into `Release` and `Master`.
Following the release of ACE 3.4.1, we have adopted a system involving collaborative project goals. Following `MINOR` releases the ACE development team will decide on a goal to work towards for the next minor increment (whether that be developing a new feature, overhauling an existing feature or simply enhancing a certain area of the project).

As ACE is primarily a hobby project, project goals will never operate on a fixed deadline and nobody is required to contribute to them. They are simply a mechanism of directing the project's development between versions.

Individual developers are free to continue working on the project at their own discretion and releases will otherwise operate as usual. Meaning that if features unrelated to the goal are complete, there will still be a minor version increment when the next release is made.

Whenever a project goal is chosen:

* A new issue will be made for the purpose of discussing and documenting the current goal's development in a centralized location.
* A new branch originating from master will be made to develop collaboratively off of until the work is ready to be merged back in.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate on why that is required?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since releases can still occur in parallel to the development of these goals we can't have unfinished work sitting in the master branch

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This kind of goes against the mentality of creating changes that work independently. I feel like it would work a lot better to just continue with the previous way of doing things, but implement a way of directing progress towards the project goals.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see it as a slightly altered git flow workflow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will basically be continuing with the previous way of doing things

Having a branch off of master is exactly what we've been doing for features already 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So basically there is no difference in the development process, just documentation of how it's been done so far anyways?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That fact that you're asking makes me think the documentation isn't clear enough 😝

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, it's just this line that confuses me 😁 :

Following the release of ACE 3.4.1


## 3 Branching and releases

We have a release scheduled every 2 weeks on a Tuesday. On the Friday before release, the project management will decide whether or not this scheduled release will continue. When continuing with the release, the current `master branch` will be merged into the `release branch`. The release branch will not contain any direct commits and no other branches will be merged into this branch. The exception being `hotfixes`, which are branched off `Release` and merged back into `Release` and `Master`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The every 2 weeks is deprecated.


`Hotfixes` are fixes for critical bugs that prevent stable gameplay with the currently available version of ACE3.

During this release process between the Friday and Tuesday, the day of release, work can continue on as normal on the `Master branch`. This includes new features, bug fixes that won't make it for release or other work. These will not be merged into the `Release branch` until the next release cycle, normally 2 weeks later.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do it like that rather:

master branch
release branch


### 2.1 Branching
### 3.1 Branching

* New features, bug fixes that are not a hotfix or other work will always be branched off `master` or another branch but never a `hotfix` or the `Release branch`.
* New features, bug fixes that are not a hotfix or other work will always be branched off `master` or another branch but never a `hotfix` or the `Release branch`.
* Hotfixes are always branched off the `Release branch`
* The release branch is never merged or deleted. Only master or hotfixes are allowed to merge into the `Release branch`.
* The release branch is never merged or deleted. Only master or hotfixes are allowed to merge into the `Release branch`.

### 2.2 Diagram
### 3.2 Diagram

<a href="{{ site.baseurl }}/img/wiki/development/release_and_branching.jpg"><img src="{{ site.baseurl }}/img/wiki/development/release_and_branching.jpg" alt="Release and branching flowchart" /></a>