From 3e0c69be5e2f48ddbc1b4c786be353a4ed90e869 Mon Sep 17 00:00:00 2001 From: Athanasius Date: Mon, 31 Jan 2022 15:41:25 +0000 Subject: [PATCH] docs: Pass for config.py -> config/__init__.py and related changes --- Contributing.md | 11 ++++++----- docs/Releasing.md | 21 +++++++++++---------- tests/{config.py => config}/_old_config.py | 0 tests/{config.py => config}/test_config.py | 0 4 files changed, 17 insertions(+), 15 deletions(-) rename tests/{config.py => config}/_old_config.py (100%) rename tests/{config.py => config}/test_config.py (100%) diff --git a/Contributing.md b/Contributing.md index e61fe764..02919c2f 100644 --- a/Contributing.md +++ b/Contributing.md @@ -191,9 +191,10 @@ only the 'C' (Patch) component. Going forwards we will always use the full [Semantic Version](https://semver.org/#semantic-versioning-specification-semver) and 'folder style' tag names, e.g. `Release/Major.Minor.Patch`. -Currently the only file that defines the version code-wise is `config.py`. -`Changelog.md` and `edmarketconnector.xml` are another matter handled as part -of [the release process](docs/Releasing.md#distribution). +Currently, the only file that defines the version code-wise is +`config/__init__.py`. `Changelog.md` and `edmarketconnector.xml` are another +matter handled as part of +[the release process](docs/Releasing.md#distribution). --- @@ -216,12 +217,12 @@ re-introduce a bug down the line. We use the [`pytest`](https://docs.pytest.org/en/stable/) for unit testing. The files for a test should go in a sub-directory of `tests/` named after the -(principal) file that contains the code they are testing. e.g. for +(principal) file or directory that contains the code they are testing. e.g. for journal_lock.py the tests are in `tests/journal_lock.py/test_journal_lock.py`. The `test_` prefix on `test_journal_lock.py` is necessary in order for `pytest` to recognise the file as containing tests to be run. The sub-directory avoids having a mess of files in `tests`, particularly when -there might be supporting files, e.g. `tests/config.py/_old_config.py` or files +there might be supporting files, e.g. `tests/config/_old_config.py` or files containing test data. Invoking just a bare `pytest` command will run all tests. diff --git a/docs/Releasing.md b/docs/Releasing.md index 50f5d0d6..73114b4c 100644 --- a/docs/Releasing.md +++ b/docs/Releasing.md @@ -17,7 +17,8 @@ this document aims to enable anyone to quickly get up to speed on how to: available versions and asks the user to upgrade. Note that for Windows only a 32-bit application is supported at this time. -This is principally due to the Windows Registry handling in config.py. +This is principally due to the Windows Registry handling in +`config/windows.py`. # Environment @@ -103,7 +104,7 @@ that. registry entries on Windows. 1. Application names, version and URL of the file with latest release - information. These are all in the `config.py` file. See the + information. These are all in the `config/__init__.py` file. See the `from config import ...` lines in setup.py. 1. `appname`: The short appname, e.g. 'EDMarketConnector' 2. `applongname`: The long appname, e.g. 'E:D Market Connector' @@ -206,24 +207,24 @@ following. 1. You should by this time know what changes are going into the release, and which branch (stable or beta) you'll be ultimately updating. -1. So as to make backing out any mistakes easier create a new branch for this +2. So as to make backing out any mistakes easier create a new branch for this release, using a name like `release-4.0.2`. Do not use the tag `Release/4.0.2` form, that could cause confusion. 1. `git checkout stable` # Or whichever other branch is appropriate. 1. `git pull origin` # Ensures local branch is up to date. 1. `git checkout -b release-4.0.2` -1. Get all the relevant code changes into this branch. This might mean +3. Get all the relevant code changes into this branch. This might mean merging from another branch, such as an issue-specific one, or possibly cherry-picking commits. See [Contributing Guidelines](../Contributing.md) for how such branches should be named. -1. You should have already decided on the new -[Version String](#Version-Strings), as it's specified in `config.py`. You'll -need to redo the `.msi` build if you forgot. **Remember to do a fresh git -commit for this change.** +4. You should have already decided on the new +[Version String](#Version-Strings), as it's specified in `config/__init__.py`. +You'll need to redo the `.msi` build if you forgot. **Remember to do a fresh +git commit for this change.** -1. Prepare a changelog text for the release. You'll need this both for the +5. Prepare a changelog text for the release. You'll need this both for the GitHub release and the contents of the `edmarketconnector.xml` file if making a `stable` release, as well as any social media posts you make. 1. The primary location of the changelog is [Changelog.md](../Changelog.md) - @@ -408,7 +409,7 @@ changelog text to the correct section(s): `https://raw.githubusercontent.com/EDCD/EDMarketConnector/releases/edmarketconnector.xml` - as per `config.py` `update_feed`. + as per `config/__init__.py` `update_feed`. NB: It can take some time for GitHub to show the changed edmarketconnector.xml contents to all users. diff --git a/tests/config.py/_old_config.py b/tests/config/_old_config.py similarity index 100% rename from tests/config.py/_old_config.py rename to tests/config/_old_config.py diff --git a/tests/config.py/test_config.py b/tests/config/test_config.py similarity index 100% rename from tests/config.py/test_config.py rename to tests/config/test_config.py