Add initial documentation of focus feature system #3029
Conversation
As was discussed in the development meeting of 12/12/2015, we're implementing a new system of setting a specific goal to work towards between versions (dubbed 'project goals'). This is not a commitment of any kind, but rather a means of providing direction for collaborative development to focus in. Initial explanation aims to make the intentions of the system clear and eliminate any potential for false expectations.
|
@acemod If you could check over this and make sure it matches what we discussed (make amendments as necessary) that'd be great 👍 |
| 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. |
There was a problem hiding this comment.
Can you elaborate on why that is required?
There was a problem hiding this comment.
Since releases can still occur in parallel to the development of these goals we can't have unfinished work sitting in the master branch
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
see it as a slightly altered git flow workflow.
There was a problem hiding this comment.
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 😄
There was a problem hiding this comment.
So basically there is no difference in the development process, just documentation of how it's been done so far anyways?
There was a problem hiding this comment.
That fact that you're asking makes me think the documentation isn't clear enough 😝
There was a problem hiding this comment.
Nope, it's just this line that confuses me 😁 :
Following the release of ACE 3.4.1
|
Thanks @SilentSpike. I will look at this more closely in a few hours. |
|
👍 from me. |
kymckay
changed the title
|
|
||
| ## 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`. | ||
|
|
||
| `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. |
There was a problem hiding this comment.
Can we do it like that rather:
masterbranch
releasebranch
- Standardized formatting of branch names - Removed outdated 2 week schedule information - Removed unused branching strategy for project goals
# Conflicts: # wiki/development/branching-and-release.md
|
Think this is ready to be merged! |
|
... :) |
As was discussed in the development meeting of 12/12/2015, we're implementing a new system of setting a specific goal to work towards between versions (dubbed 'project goals'). This is not a commitment of any kind, but rather a means of providing direction for collaborative development to focus in.
Initial explanation aims to make the intentions of the system clear and eliminate any potential for false expectations.