docs: refresh project status notes for release workflow
This commit is contained in:
+15
-22
@@ -1,4 +1,4 @@
|
|||||||
# Project status — fullupgrade
|
# Project Status — fullupgrade
|
||||||
|
|
||||||
Last updated: 2026-04-27
|
Last updated: 2026-04-27
|
||||||
|
|
||||||
@@ -31,38 +31,36 @@ Notes:
|
|||||||
|
|
||||||
Recommendations:
|
Recommendations:
|
||||||
- keep documenting the system impact clearly
|
- keep documenting the system impact clearly
|
||||||
- consider whether `pacman -Sc` is the right cache cleanup level for every use case
|
|
||||||
|
|
||||||
### 2) `makerelease.sh`
|
### 2) `makerelease.sh`
|
||||||
Current behavior:
|
Current behavior:
|
||||||
- takes `VERSION` and `MESSAGE` as arguments
|
- supports explicit versions like `1.2.3`
|
||||||
|
- supports version increments with `+0.0.1`, `+0.1`, and `+1`
|
||||||
|
- supports `--dry-run` to print the computed release version
|
||||||
- checks that the current branch is `dev`
|
- checks that the current branch is `dev`
|
||||||
|
- verifies the working tree is clean
|
||||||
|
- checks that the target tag does not already exist
|
||||||
- checks out `main`
|
- checks out `main`
|
||||||
- merges `dev` into `main`
|
- merges `dev` into `main`
|
||||||
- pushes the branch
|
- pushes the branch
|
||||||
- creates an annotated tag
|
- creates an annotated tag
|
||||||
- pushes tags
|
- pushes tags
|
||||||
- returns to `dev`
|
- attempts to return to the original branch on exit
|
||||||
|
|
||||||
Notes:
|
Notes:
|
||||||
- the script currently does not use `set -euo pipefail`
|
- the script uses `set -euo pipefail`
|
||||||
- there is no check for a clean working tree
|
- the release tag message is now generated automatically as `Release <version>`
|
||||||
- there is no validation of the release message
|
- the script no longer requires a separate release message argument
|
||||||
- there is no guard against duplicate tags
|
- the current increment logic assumes simple dotted numeric tags
|
||||||
- returning to `dev` is not protected if a command fails
|
|
||||||
|
|
||||||
Recommendations:
|
Recommendations:
|
||||||
- add `set -euo pipefail`
|
- consider validating the version format more strictly if release rules grow
|
||||||
- verify the Git status before releasing
|
- keep the dry-run behavior documented and aligned with the script
|
||||||
- validate `VERSION` and `MESSAGE`
|
|
||||||
- prevent duplicate tags
|
|
||||||
- use a `trap` to return to the initial branch on failure
|
|
||||||
- improve the help output
|
|
||||||
|
|
||||||
### 3) `README.md`
|
### 3) `README.md`
|
||||||
Current status:
|
Current status:
|
||||||
- the README has a first complete pass in English
|
- the README documents both scripts in English
|
||||||
- it explains both scripts, their requirements, usage, warnings, and an example release command
|
- it now includes release increments and dry-run usage for `makerelease.sh`
|
||||||
|
|
||||||
Recommendations:
|
Recommendations:
|
||||||
- keep it aligned with the actual script behavior
|
- keep it aligned with the actual script behavior
|
||||||
@@ -75,11 +73,6 @@ This file should be updated whenever:
|
|||||||
- new constraints or design decisions are introduced
|
- new constraints or design decisions are introduced
|
||||||
- release workflow rules evolve
|
- release workflow rules evolve
|
||||||
|
|
||||||
## Current priorities
|
|
||||||
1. Secure the Bash scripts
|
|
||||||
2. Keep documentation aligned with the scripts
|
|
||||||
3. Make the release workflow more robust
|
|
||||||
|
|
||||||
## Maintenance notes
|
## Maintenance notes
|
||||||
- Always keep the README, the scripts, and this file consistent.
|
- Always keep the README, the scripts, and this file consistent.
|
||||||
- If a script changes, update this note immediately.
|
- If a script changes, update this note immediately.
|
||||||
|
|||||||
-86
@@ -1,86 +0,0 @@
|
|||||||
# Project Status — fullupgrade
|
|
||||||
|
|
||||||
Last updated: 2026-04-27
|
|
||||||
|
|
||||||
## Project goal
|
|
||||||
This repository contains two Bash scripts for system administration and Git release management:
|
|
||||||
- `fullupgrade`: Arch Linux maintenance script
|
|
||||||
- `makerelease.sh`: Git release automation script
|
|
||||||
|
|
||||||
The project is intentionally minimal and centered on these two scripts.
|
|
||||||
|
|
||||||
## Current structure
|
|
||||||
- `fullupgrade`: system update and cleanup
|
|
||||||
- `makerelease.sh`: release workflow from `dev` to `main`
|
|
||||||
- `README.md`: English documentation with usage, warnings, and examples
|
|
||||||
- `LICENSE`: GPLv3
|
|
||||||
|
|
||||||
## Current analysis
|
|
||||||
|
|
||||||
### 1) `fullupgrade`
|
|
||||||
Current behavior:
|
|
||||||
- updates `archlinux-keyring`
|
|
||||||
- runs `pacman -Syu --noconfirm`
|
|
||||||
- removes orphaned packages only when any are found
|
|
||||||
- cleans the pacman cache
|
|
||||||
|
|
||||||
Notes:
|
|
||||||
- the script already uses `set -euo pipefail`
|
|
||||||
- it checks for root privileges before running package operations
|
|
||||||
- it can have a significant system impact
|
|
||||||
|
|
||||||
Recommendations:
|
|
||||||
- keep documenting the system impact clearly
|
|
||||||
- consider whether `pacman -Sc` is the right cache cleanup level for every use case
|
|
||||||
|
|
||||||
### 2) `makerelease.sh`
|
|
||||||
Current behavior:
|
|
||||||
- supports explicit versions like `1.2.3`
|
|
||||||
- supports version increments with `+0.0.1`, `+0.1`, and `+1`
|
|
||||||
- supports `--dry-run` to print the computed release version
|
|
||||||
- checks that the current branch is `dev`
|
|
||||||
- verifies the working tree is clean
|
|
||||||
- checks that the target tag does not already exist
|
|
||||||
- checks out `main`
|
|
||||||
- merges `dev` into `main`
|
|
||||||
- pushes the branch
|
|
||||||
- creates an annotated tag
|
|
||||||
- pushes tags
|
|
||||||
- attempts to return to the original branch on exit
|
|
||||||
|
|
||||||
Notes:
|
|
||||||
- the script uses `set -euo pipefail`
|
|
||||||
- the release tag message is now generated automatically as `Release <version>`
|
|
||||||
- the script no longer requires a separate release message argument
|
|
||||||
- the current increment logic assumes simple dotted numeric tags
|
|
||||||
|
|
||||||
Recommendations:
|
|
||||||
- consider whether tags may need a `v` prefix in the future
|
|
||||||
- consider validating the version format more strictly if release rules grow
|
|
||||||
- keep the dry-run behavior documented and aligned with the script
|
|
||||||
|
|
||||||
### 3) `README.md`
|
|
||||||
Current status:
|
|
||||||
- the README documents both scripts in English
|
|
||||||
- it now includes release increments and dry-run usage for `makerelease.sh`
|
|
||||||
|
|
||||||
Recommendations:
|
|
||||||
- keep it aligned with the actual script behavior
|
|
||||||
- add more examples only if they improve clarity
|
|
||||||
|
|
||||||
## Project tracking rules
|
|
||||||
This file should be updated whenever:
|
|
||||||
- script behavior changes
|
|
||||||
- documentation changes materially
|
|
||||||
- new constraints or design decisions are introduced
|
|
||||||
- release workflow rules evolve
|
|
||||||
|
|
||||||
## Current priorities
|
|
||||||
1. Secure the Bash scripts
|
|
||||||
2. Keep documentation aligned with the scripts
|
|
||||||
3. Make the release workflow more robust
|
|
||||||
|
|
||||||
## Maintenance notes
|
|
||||||
- Always keep the README, the scripts, and this file consistent.
|
|
||||||
- If a script changes, update this note immediately.
|
|
||||||
- If a new usage rule appears, document it here.
|
|
||||||
Reference in New Issue
Block a user