Skip to content

update dev strat #5

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

Open
iFoggz wants to merge 1 commit into
base: master
Choose a base branch
from
Open

update dev strat #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
22 changes: 15 additions & 7 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,19 +9,27 @@ information or see https://opensource.org/licenses/MIT.

## Development Process

Developers work in their own trees, then submit pull requests to the development branch when they think their feature or bug fix is ready.

The patch will be accepted if there is broad consensus that it is a good thing. Developers should expect to rework and resubmit patches if they don't match the project's coding conventions see [developer-notes.md](https://github.com/BITCORNProject/BITCORN/blob/master/doc/developer-notes.md) or are controversial. We require multiple developers to review code changes. A developer who submits a pull request cannot approve the pull request themselves.

Milestones should be made to signify a future release. Bugs that are not network breaking or new/changed features should be tagged to a milestone. Not every new addition or change has to be tagged to the next milestone. Milestones are like a roadmap of the future. They are effective to set expectations of what is to be expected or achieved for future release(s). It is not uncommon to push tasks to a future milestone if the expectation of the said task cannot be completed in time or doesn't fit the next release time frame. Milestones also keep development tidy for testing of what should be expected for next release.

The `master` branch is regularly built and tested, but is not guaranteed to be
completely stable. [Tags](https://github.com/BITCORNProject/Bitcorn-Test/tags) are created
regularly to indicate new official, stable release versions of Bitcorn Core.

The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md)
and useful hints for developers can be found in [doc/developer-notes.md](doc/developer-notes.md).
## Branching Strategy

Bitcorn uses four branches to ensure stability without slowing down the pace of the daily development activities - development, staging, master and hotfix.

The development branch is used for day-to-day activities. It is the most active branch and is where pull requests go by default. This branch may contain code which is not yet stable or ready for production, so it should only be executed on testnet to avoid disruption to production network.

When a decision has been made that the development branch should be moving towards a final release it is merged to staging where no new development takes place. This branch is purely to stabilize the code base and squash out bugs rained down from development. This is Bitcorn's beta testing phase.

## Testing
Once the staging branch is stable and runs smoothly, it is merged to master, a tag is created, and a release is made available to the public.

Testing and code review is the bottleneck for development; we get more pull
requests than we can review and test on short notice. Please be patient and help out by testing
other people's pull requests, and remember this is a security-critical project where any mistake might cost people
lots of money.
When a bug is found in a production version and an update needs to be released quickly, the changes go into a hotfix branch for testing before being merged to master for release. This allows for production updates without having to merge straight to master if the staging branch is busy.

### Automated Testing

Expand Down