40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
# Dev Notes
|
||
|
||
### Version Bumping
|
||
|
||
We use a tool called `bump2version` to manage bumping versions in the project. To ensure a clean git history and avoid
|
||
conflicts, follow these steps when bumping the version:
|
||
|
||
1. **Before bumping the version**, always `git pull` to ensure you have the latest changes from the repository.
|
||
2. Ensure no other copies of the repo are being worked on or committed before running the `bump2version` tool.
|
||
3. Bump the version using the command:
|
||
|
||
```bash
|
||
bumpversion [major|minor|patch]
|
||
```
|
||
|
||
This will:
|
||
|
||
1. Update the version in the VERSION file.
|
||
1. Automatically commit the version bump.
|
||
1. Create a Git tag with the new version (e.g., vALPHA-2.0.1).
|
||
|
||
Push your changes and the tag to the remote repository after bumping the version:
|
||
|
||
```bash
|
||
git push origin master --tags
|
||
```
|
||
|
||
ersioning Guidelines
|
||
|
||
We follow a versioning structure of ALPHA-major.minor.patch. Here’s a breakdown of the versioning rules:
|
||
|
||
- **Major**: The major version is incremented for significant changes that introduce new features or incompatible API
|
||
changes.
|
||
- **Minor**: The minor version is incremented for adding new functionality in a backwards-compatible manner.
|
||
- **Patch**: The patch version is incremented for bug fixes and minor improvements that don’t affect the existing
|
||
functionality.
|
||
|
||
This will be managed by a CI/CD pipeline (or Gitea Actions) later down the line, but for now, follow these manual steps
|
||
carefully to ensure version consistency.
|