muskit/spice2x.github.io
0
0
Fork 0
mirror of https://github.com/spice2x/spice2x.github.io.git synced 2026-08-01 22:30:42 -07:00
Code Issues Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md

Browse Source
This commit is contained in:
sp2xdev
2024-07-15 19:03:50 -07:00
committed by GitHub
parent b59db8dd14
commit 962db5d4d4
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+1 -1
View File
@@ -13,7 +13,7 @@ Baseline rules for patch submissions are as follows. Any patches violating the r
The biggest risk in making code changes to spice is the risk of regressions. There is a **lot** of shared code used by many different games, reaching back game versions that are more than a decade old. It is practically impossible to test all supported games and versions. The biggest risk in making code changes to spice is the risk of regressions. There is a **lot** of shared code used by many different games, reaching back game versions that are more than a decade old. It is practically impossible to test all supported games and versions.
Additionally, there's a lot of code that get exercised on specific hardware - including hardware that you probably don't have access to (e.g., ICCA reader, real cabinet I/O, specific game controllers, particular brand of touch screens...) Additionally, there's a lot of code that get exercised on specific hardware - including hardware that you probably don't have access to (e.g., ICCA reader, real cabinet I/O, specific model of a IIDX controller, particular brand of touch screens...)
Therefore, when making code changes, please by extremely careful about containing / scoping your changes. Make targeted bug fixes scoped to handful of game versions and hardware configuration. When adding new features, make it off by default, unless there is a really good reason to make it the default. If you make a new default, add an option that disables it so that users can opt out as needed. Therefore, when making code changes, please by extremely careful about containing / scoping your changes. Make targeted bug fixes scoped to handful of game versions and hardware configuration. When adding new features, make it off by default, unless there is a really good reason to make it the default. If you make a new default, add an option that disables it so that users can opt out as needed.