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.
|