Revise release process
Version bumping was causing an issue where a new git tag and commit was created before Cargo.toml was updated. This merge turns off auto tag and commit creation and moves them to the process document.
This commit is contained in:
parent
623e6621f3
commit
c69ed60cd2
@ -1,8 +1,8 @@
|
|||||||
[bumpversion]
|
[bumpversion]
|
||||||
current_version = 0.1.8
|
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]
|
[bumpversion:file:veilid-server/Cargo.toml]
|
||||||
search = name = "veilid-server"
|
search = name = "veilid-server"
|
||||||
|
65
RELEASING.md
65
RELEASING.md
@ -2,24 +2,50 @@
|
|||||||
|
|
||||||
## Introduction
|
## 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:
|
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
|
## 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.
|
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_
|
Loading…
Reference in New Issue
Block a user