From 016244bb1b124137c4bb68a2a21a5f55d831d8ba Mon Sep 17 00:00:00 2001 From: Thomas Walker Lynch Date: Fri, 19 Sep 2025 23:50:16 -0700 Subject: [PATCH] docs cleanup --- .../{ => RT_code_format}/RT_code_format.org | 0 .../bracketed_phrases_section.txt | 0 ...how_to_use_project_directory_structure.txt | 59 ------------------- 3 files changed, 59 deletions(-) rename document/conventions/{ => RT_code_format}/RT_code_format.org (100%) rename document/conventions/{ => RT_code_format}/bracketed_phrases_section.txt (100%) delete mode 100644 document/conventions/how_to_use_project_directory_structure.txt diff --git a/document/conventions/RT_code_format.org b/document/conventions/RT_code_format/RT_code_format.org similarity index 100% rename from document/conventions/RT_code_format.org rename to document/conventions/RT_code_format/RT_code_format.org diff --git a/document/conventions/bracketed_phrases_section.txt b/document/conventions/RT_code_format/bracketed_phrases_section.txt similarity index 100% rename from document/conventions/bracketed_phrases_section.txt rename to document/conventions/RT_code_format/bracketed_phrases_section.txt diff --git a/document/conventions/how_to_use_project_directory_structure.txt b/document/conventions/how_to_use_project_directory_structure.txt deleted file mode 100644 index fd2c933..0000000 --- a/document/conventions/how_to_use_project_directory_structure.txt +++ /dev/null @@ -1,59 +0,0 @@ -### Work Flow - -#### 1. Project Administrator - -1.1. Download the project from GitHub. -1.2. Install the required tools. -1.3. Explain the workflows and where things are located to project members. -1.4. Perform Major and Minor Release administration. - -#### 2. Developer - -2.1. From the Harmony directory, run `> source env_developer` to set up the - developer environment. -2.2. Use `> make` to build the project, and `> release` to copy relevant files - to `$REPO_HOME/release` for testing. -2.3. The tester will test the release candidate. - -#### 3. Tester - -3.1. From the Harmony directory, run `> source env_tester` to set up the tester - environment. -3.2. Use `> make` to build the tests, and `> shell/test_` to run a test. - Alternatively, you can cd into one of the test directories, source the - environment for that test, and run it manually. -3.3. Testing and development will likely iterate until the release candidate is - ready to be turned into a versioned release. - -#### 4. Major Release - -4.1. The release candidate is located in the `$REPO_HOME/release` directory and - has passed testing. -4.2. Check that the program `$REPO_HOME/tool_shared/bespoke/version` outputs the - correct information. If necessary, modify it. -4.3. A new branch is created in the project for the release, named - `release_v.0`, where `v.0` is the version number from the `version` - program. The minor version number is set to zero (`.0`), and it is assumed - that this will be the case after each major release. -4.4. Rename the release directory to `$REPO_HOME/release_v.0`, and create a - new empty `$REPO_HOME/release` directory. The new empty release directory - can be used by developers who download the project and make local edits, as - the build scripts target this directory. - -#### 5. Minor Release - -If urgent changes need to be made to the most recent major release, these edits -should be made on the corresponding major release branch. The developer makes -the edits, and the tester tests the release candidate as usual. The `version` -program is updated. Once the release candidate is finalized, rename the -directory to `release_v.`, where `` is the minor version number. If -needed, merge the changes into the `core_developer_branch`. - ---- - -### Tips: - -- If you are acting in multiple roles (e.g., developer, tester, and project - administrator), keep separate terminal shells open for each role. This way, - the environment will remain correctly configured for the tasks related to - each role. -- 2.20.1