Housekeeping (#293)

.github/workflows/linux.yml

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

.github/workflows/windows.yml

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

CONTRIBUTING.md

@@ -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
 

deps/commandline

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

vcpkg

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