BeamMP/BeamMP-Server
1
0
Fork 0
mirror of https://github.com/BeamMP/BeamMP-Server.git synced 2025-07-04 00:36:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

Housekeeping (#293)

Browse Source
This commit is contained in:
Lion 2024-02-24 20:36:12 +01:00 committed by GitHub
commit 0146a1cbe8
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 34 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.github/workflows/linux.yml vendored
View File

@ -1,7 +1,11 @@
name: Linux name: Linux
on: [push] on:
push:
branches:
- 'develop'
- 'minor'
pull_request:
env: env:
VCPKG_BINARY_SOURCES: "clear;x-gha,readwrite" VCPKG_BINARY_SOURCES: "clear;x-gha,readwrite"

7
.github/workflows/windows.yml vendored
View File

@ -1,6 +1,11 @@
name: Windows name: Windows
on: [push] on:
push:
branches:
- 'develop'
- 'minor'
pull_request:
env: env:
VCPKG_DEFAULT_TRIPLET: x64-windows-static VCPKG_DEFAULT_TRIPLET: x64-windows-static

23
CONTRIBUTING.md
View File

@ -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. 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 ## Branches
### Which branch should I base my work on? - `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.
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`.
## Unit tests & CI/CD ## Unit tests & CI/CD

2
deps/commandline vendored

@ -1 +1 @@
Subproject commit b2a29733f96eee96d3abc023b467821238f4d4b0 Subproject commit 04952e4811e7d44708e64986bbc82fdc3485c800

2
vcpkg

@ -1 +1 @@
Subproject commit 83972272512ce4ede5fc3b2ba98f6468b179f192 Subproject commit 6978381401d33a5ad6a3385895d12e383083712a