Merge branch 'Revise-version-bumping-process' into 'main'

Revise release process

See merge request veilid/veilid!135

.bumpversion.cfg

@@ -1,8 +1,8 @@
 [bumpversion]
 current_version = 0.1.8
-tag = True
+#tag = True
-commit = True
+#commit = True
-message = 'Version update: {current_version} → {new_version}'
+#message = 'Version update: {current_version} → {new_version}'
 
 [bumpversion:file:veilid-server/Cargo.toml]
 search = name = "veilid-server"

RELEASING.md

@@ -2,24 +2,50 @@
 
 ## Introduction
 
-Veilid is a monorepo consisting of several projects:  
+This guide outlines the process for releasing a new version of Veilid. The end result is an update of the package repositories and Pypi.
-(checked boxes are released as packages)
 
-## Release Mechanism
+## Create a Gitlab Release
 
 Releases happen via a CI/CD pipeline. The release process flows as follows:
-1. Maintainer responds to a merge request (MR):
-    a. Evaluate the MR's adherence to the published requirements and if automatic tests passed.
-    b. (Optional) Perform the merge in a local dev environment if testing is required beyond the standard Earthly tests.
-    c. If everything checks out, MR meets the published requirements, and tests passed, execute the merge functions in the Gitlab UI.
-2. Maintainer performs version bump:
-    a. Update your local copy of `main` to mirror the newly merged version
-    b. Execute the bumpversion.py process.
-    c. Push your local 'main' to the upstream origin 'main' `git push`
-    d. Push the new tag to the upstream origin `git push "tag name made in step 2d"`
-    e. Ensure the package/release/distribute pipeline autostarted in the Gitlab UI
 
-Tags serve as a historical record of what repo versions were successfully released at which version numbers.
+1. Complete outstanding merge requests (MR):
+    
+    1.1 Evaluate the MR's adherence to the published requirements and if automatic tests passed.
+    
+    1.2 (Optional) Perform the merge in a local dev environment if testing is required beyond the standard Earthly tests.
+    
+    1.3 If everything checks out, MR meets the published requirements, and tests passed, execute the merge functions in the Gitlab UI.
+
+2. Maintainer performs version bump:
+    
+    2.1 Update your local copy of `main` to mirror the newly merged upstream `main`
+
+    2.2 Ensure the (CHANGELOG)[./CHANGELOG.md] is updated
+    
+    2.3 Activate your bumpversion Python venv (see bumpversion setup section for details)
+
+    2.4 Execute version_bump.sh with the appropriate parameter (patch, minor, or major). This results in all version entries being updated and a matching git tag created locally.
+
+    2.5 Add all changes `git add *`
+
+    2.6 Git commit the changes with the following message: `Version update: v{current_version} → v{new_version}`
+
+    2.7 Create the Git tag `git tag v{new_version}`
+    
+    2.8 Push your local 'main' to the upstream origin 'main' `git push`
+    
+    2.9 Push the new tag to the upstream origin `git push origin {tag name made in step 2.7}` i.e. `git push origin v0.1.5`
+    
+    2.10 Ensure the package/release/distribute pipeline autostarted in the Gitlab UI
+
+Git tags serve as a historical record of what repo versions were successfully released at which version numbers.
+
+## Publish to Pypi
+
+1. Change directory to veilid-python
+2. Install Poetry and configure the Pypi credentials, if not already accomplished.
+3. Execute `poetry build`
+4. Execute `poetry publish`
 
 ## Reverting Releases
 
@@ -86,3 +112,14 @@ All versions of Veilid Rust crates as well as `veilid-python` and `veilid-flutte
 
 The `version_bump.sh` script should be run on every release to stable. All of the Rust crates are versioned together and should have the same version, as well as the `veilid-python` Python package and `veilid-flutter` Flutter plugin.
 
+## Bumpversion Setup and Usage
+### Install Bumpversion
+1. Create a Python venv for bumpversion.py. Mine is in my home dir so it persists when I update my local Veilid `main`.
+
+    `python3 -m venv ~/bumpversion-venv`
+2. Activate the venv. `source ~/bumpversion-venv/bin/activate`
+3. Install bumpversion. `pip3 install bumpversion`
+
+### Activate venv for version bumping step of the release process
+1. Activate the venv. `source ~/bumpversion-venv/bin/activate`
+2. Return to step 2.4 of _Create a Gitlab Release_