mirror of
https://github.com/BeamMP/BeamMP-Server.git
synced 2025-07-03 16:25:35 +00:00
Housekeeping (#293)
This commit is contained in:
commit
0146a1cbe8
8
.github/workflows/linux.yml
vendored
8
.github/workflows/linux.yml
vendored
@ -1,7 +1,11 @@
|
||||
name: Linux
|
||||
|
||||
on: [push]
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- 'develop'
|
||||
- 'minor'
|
||||
pull_request:
|
||||
|
||||
env:
|
||||
VCPKG_BINARY_SOURCES: "clear;x-gha,readwrite"
|
||||
|
7
.github/workflows/windows.yml
vendored
7
.github/workflows/windows.yml
vendored
@ -1,6 +1,11 @@
|
||||
name: Windows
|
||||
|
||||
on: [push]
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- 'develop'
|
||||
- 'minor'
|
||||
pull_request:
|
||||
|
||||
env:
|
||||
VCPKG_DEFAULT_TRIPLET: x64-windows-static
|
||||
|
@ -53,11 +53,28 @@ Do **NOT** pull with merge. This is the default git behavior for `git pull`, but
|
||||
|
||||
The only acceptable merge commits are those which actually merge functionally different branches into each other, for example for merging one feature branch into another.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Making an issue and fixing it
|
||||
|
||||
1. Create an issue detailing the feature or bug.
|
||||
2. Assign a milestone to the issue, or wait for a maintainer to add a milestone to your issue.
|
||||
3. Fork the repository and base your work on the branch mentioned in the milestone attached to your issue (e.g. `v3.0.0 (develop)` -> `develop`).
|
||||
4. Program your feature or bug fix.
|
||||
5. Open a PR that references the issue by number in the format: `#12345`.
|
||||
6. Someone will review your PR and merge it, or ask for changes.
|
||||
|
||||
### Fixing an existing issue
|
||||
|
||||
1. Fork the repository and base your work on the branch mentioned in the milestone attached to your issue (e.g. `v3.0.0 (develop)` -> `develop`).
|
||||
2. Program your feature or bug fix.
|
||||
3. Open a PR that references the issue by number in the format: `#12345`.
|
||||
4. Someone will review your PR and merge it, or ask for changes.
|
||||
|
||||
## Branches
|
||||
|
||||
### Which branch should I base my work on?
|
||||
|
||||
Each *feature* or *bug-fix* is implemented on a new Git branch, branched off of the branch it should be based on. The `master` branch is usually stable, so we don't do development on it. It is always a safe bet to branch off of `master`, but it may be more work to merge later. Branches to base your work on are usually branches like `rc-v3.3.0`, when the latest public version is `3.2.0`, for example. These can often be found in Pull-Requests on GitHub which are tagged `Release Candidate`.
|
||||
- `minor`: Minor releases, like `v1.2.3` -> `v1.3.0` or `v1.2.3` -> `v1.2.4`.
|
||||
- `develop`: Major releases, like `v1.2.3` -> `v2.0.0`, and larger feature/minor releases.
|
||||
|
||||
## Unit tests & CI/CD
|
||||
|
||||
|
2
deps/commandline
vendored
2
deps/commandline
vendored
@ -1 +1 @@
|
||||
Subproject commit b2a29733f96eee96d3abc023b467821238f4d4b0
|
||||
Subproject commit 04952e4811e7d44708e64986bbc82fdc3485c800
|
2
vcpkg
2
vcpkg
@ -1 +1 @@
|
||||
Subproject commit 83972272512ce4ede5fc3b2ba98f6468b179f192
|
||||
Subproject commit 6978381401d33a5ad6a3385895d12e383083712a
|
Loading…
x
Reference in New Issue
Block a user