From d3524895bde8ccf09af1935bcf0666304648e25a Mon Sep 17 00:00:00 2001 From: Eamonn Rea Date: Fri, 15 Mar 2024 18:13:25 +0000 Subject: [PATCH] Update CONTRIBUTING.md with More Up-To-Date Contributing Information (#1062) --- CONTRIBUTING.md | 27 ++++++++++++++++++++------- steamtinkerlaunch | 2 +- 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8b50a6c3..3c9906a0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -28,10 +28,21 @@ You are free to open draft PRs as well if your feature is still in the works but ### Naming There are no strict rules on how to name or format your pull requests. Just try to make it descriptive, informative and keep it clean :-) +### Versioning +**Note:** Version strings don't have to be updated when submitting PRs with no code updates. You're still free to do so, but it isn't really necessary if you're not touching `steamtinkerlaunch`. It is cleaner for me though! :-) + +Before a Pull Request can be merged, the `PROGVERS` should be bumped. This value controls how config files are versioned, and how new data is pulled into them. Usually, `PROGVERS` is set to the current `major.minor` version, and then the current date plus 1 at the end. Dates follow the ISO date standard. If the current date is already used, you can adjust the revision number. The version major and minor strings don't need to be changed by you, *only the date needs to be changed*. + +That means, if you're developing a feature for SteamTinkerLaunch v15.2 on on August 14th 2025, you would set the string as `v15.2.20250414-1`. If this date was already used, you would change the `-1` to be `-2` in this case, or `-3` and so on. Take a look around commits, and multiple commits in the same day, to see the diff on how `PROGVERS` is bumped. As examples, take a look at [`62aec11`](https://github.com/sonic2kk/steamtinkerlaunch/commit/62aec1124e19798509d203c6e28c24b28ac11157) for a version bump example, and its follow-up [`c2071ea`](https://github.com/sonic2kk/steamtinkerlaunch/commit/c2071ea044277bd87a02aa51764ac88b42aae298) for a revision bump example. + +During development, you can set `PROGVERS` to any value you want, but you may want to suffix it with the branch name in brackets. In the above example, if your branch is called `awesomer-steamtinkerlaunch`, then your version string during development might be `v15.2.20250414-1 (awesomer-steamtinkerlaunch)`. Before merging, however, this should be cleaned up once all feedback is addressed. You may also update the string during a rebase. + +See also: **[Development Tips/Testing your Development Version](#testing-your-development-version)**. + ### Commit History -It is totally fine to open a pull request with several commits, however before merging it is much preferable to have your commit history squashed at least a bit. This is in the interest of keeping the commit history relatively clean for contributions. Ideally, one PR will be merged as one commit, but if you feel your changes are better separated across a few commits, please feel free to note that in your PR. +You can open a Pull Request with several commits, GitHub's "Squash and Merge" option is usually used when merging PRs. -If you don't know how to squash commits, don't let that scare you off from contributing too much. You can do it at the end before merging, and there are plenty of helpful resources online to guide you through the process of squashing commits. +Merge commit names may be adjusted from the Pull Request title in an attempt to make the purpose clearer. Please try to name your pull requests descriptively, and if you'd _really_ prefer no rename, please mention so in your description. ### Translations If you edit any of the language files when contributing, add the string to **all** the other language files *or* update the string in other language files too if it is untranslated. For example, if you add a string to `english.txt`, and that same string is untranslated in `dutch.txt`, just copy the English string into `dutch.txt`. @@ -44,23 +55,25 @@ You are also free to translate the string, if you speak the language. But if not This section has some tips and guidance to help with writing code for SteamTinkerLaunch. ### Use ShellCheck -**Note**: You may have to use [ShellCheck v0.8.0](https://github.com/koalaman/shellcheck/releases/tag/v0.8.0) with SteamTinkerLaunch, due to an issue with memory consumption with newer versions of ShellCheck ([koalaman/shellcheck#2652](https://github.com/koalaman/shellcheck/issues/2652)). +**Note**: ShellCheck v0.9.0 is **NOT** supported due to enforcing an extended data analysis engine. ShellCheck v0.10.0 allows this to be disabled, and SteamTinkerLaunch automatically sets a directive to disable it. You can also disable it manually when running ShellCheck by using `shellcheck --extended-analysis=false steamtinkerlaunch`. There is an awesome utility called [ShellCheck](http://shellcheck.net/) which helps ensure shell code is bug-free. It is strongly recommended to use this when developing for SteamTinkerLaunch, it's a good way to catch bugs and write well structured code. There may be rare instances where ShellCheck is a bit *too* helpful. In cases like that, you can add a `shellcheck disable` check to your code. In Pull Requests and/or in a comment near that section, please note the reason for disabling that ShellCheck warning. +For more information on what causes ShellCheck issues, each of its error/warning/etc has a wiki page that can give information on how to resolve the problem. + ### Clearing Temp Files Before running development builds, it can be a good idea to clear out the `/dev/shm/steamtinkerlaunch` folder. Before each execution you can run `rm -rf /dev/shm/steamtinkerlaunch`. If you want to test SteamTinkerLaunch from a "clean" slate, you can optionally use this Python script by [tetoNidan](https://github.com/tetoNidan) to remove any SteamTinkerLaunch related files: https://gist.github.com/tetoNidan/27223269c35cb922988b6b05858d0f37/ - This may be useful to do if you want to test SteamTinkerLaunch on another machine from as fresh of a state as possible. -### Testing Development Builds -There are a few ways to test development builds of SteamTinkerLaunch. One of the first things you should do is change the `PROGVERS` at the top of the script. For development purposes you can set this to anything you like, as this will help you ensure you are definitely running the development version of SteamTinkerLaunch. You could append `-dev` to the end of the `PROGVERS`, for example. +### Testing your Development Version +There are a few ways to test features you're developing for SteamTinkerLaunch. One of the first things you should do is change the `PROGVERS` at the top of the script. For development purposes you can set this to anything you like, as this will help you ensure you are definitely running the development version of SteamTinkerLaunch. You could append `-dev` to the end of the `PROGVERS`, for example. -To run your development build of SteamTinkerLaunch, you can simply run `./steamtinkerlaunch` to execute the script. You can check the version with `./steamtinkerlaunch version`. +To run your development version of SteamTinkerLaunch, you can simply run `./steamtinkerlaunch` to execute the script. You can check the version with `./steamtinkerlaunch version`. -To run your development build of SteamTinkerLaunch through Steam, you can run `./steamtinkerlaunch compat add` and then launch your game through Steam. You shouldn't need to restart Steam for this change to take effect, as it should just change the symlink in Steam's `compatibilitytools.d` folder to point to your development script. +To run your development version of SteamTinkerLaunch through Steam, you can run `./steamtinkerlaunch compat add` and then launch your game through Steam. You shouldn't need to restart Steam for this change to take effect, as it should just change the symlink in Steam's `compatibilitytools.d` folder to point to your development script. Once you're done with development, you can go back to using your regular SteamTinkerLaunch version in one of the following ways depending on how you installed SteamTinkerLaunch: - For package manager installations, root installs (with `sudo make install`), or if SteamTinkerLaunch is otherwise on your `PATH` (like on Steam Deck with ProtonUp-Qt), you can run `steamtinkerlaunch compat add` from **outside** of your SteamTinkerLaunch development folder. This will point the symlink in Steam's `compatibilitytools.d` folder back to the original script and not your development script. diff --git a/steamtinkerlaunch b/steamtinkerlaunch index d21bc799..7a626bb1 100755 --- a/steamtinkerlaunch +++ b/steamtinkerlaunch @@ -7,7 +7,7 @@ PREFIX="/usr" PROGNAME="SteamTinkerLaunch" NICEPROGNAME="Steam Tinker Launch" -PROGVERS="v14.0.20240316-1" +PROGVERS="v14.0.20240316-2" PROGCMD="${0##*/}" PROGINTERNALPROTNAME="Proton-stl" SHOSTL="stl"