acid-info
/
development-guidelines
mirror of https://github.com/acid-info/development-guidelines.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

remove VSCode formating

This commit is contained in:
jongomez 2023-09-26 13:21:00 +01:00
parent 86ed95a331
commit 62a467878f
1 changed files with 6 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
release-delivery.md
View File

@ -12,22 +12,17 @@
- [Parallel release branches are not supported.](#parallel-release-branches-are-not-supported) - [Parallel release branches are not supported.](#parallel-release-branches-are-not-supported)
## Introduction ## Introduction
We take a similar approach to [GitHub flow](https://githubflow.github.io/) for our projects that are delivered through releases. We take a similar approach to [GitHub flow](https://githubflow.github.io/) for our projects that are delivered through releases.
## Branch Types ## Branch Types
There are two branch types: There are two branch types:
- trunk - trunk
- topic - topic
### Trunk Branch ### Trunk Branch
The trunk is your development branch, the only long-lived branch in your remote server. Use `main` for the name of this branch across all projects for consistency. It will contain your recent well-tested merged changes and must always be release-ready. No one is allowed to push to this branch directly. The trunk is your development branch, the only long-lived branch in your remote server. Use `main` for the name of this branch across all projects for consistency. It will contain your recent well-tested merged changes and must always be release-ready. No one is allowed to push to this branch directly.
### Topic Branches ### Topic Branches
Contributors will work on short-lived branches and push their changes to the remote server on a branch with the same name. They should then create a request for merging the branch into the trunk. The maintainer(s) may accept the request after reviewing the changes and when all the tests are passed to ensure nothing will break on the trunk branch by merging. Contributors will work on short-lived branches and push their changes to the remote server on a branch with the same name. They should then create a request for merging the branch into the trunk. The maintainer(s) may accept the request after reviewing the changes and when all the tests are passed to ensure nothing will break on the trunk branch by merging.
```mermaid ```mermaid
@ -49,21 +44,17 @@ Contributors will work on short-lived branches and push their changes to the rem
``` ```
## Contribution Rules ## Contribution Rules
You should strictly follow the [Contribution Rules document](/contribution-rules.md).
You should strictly follow the [Contribution Rules document](/contribution-rules.md).
## Instructions ## Instructions
### Create a New Feature ### Create a New Feature
1. Create a local branch: 1. Create a local branch:
```bash ```bash
$ git checkout -b topic-foo main $ git checkout -b topic-foo main
``` ```
2. Push your changes to a remote branch with the same name: 2. Push your changes to a remote branch with the same name:
```bash ```bash
$ git push origin topic-foo $ git push origin topic-foo
``` ```
@ -73,11 +64,9 @@ $ git push origin topic-foo
4. Delete your branch after your merge request is approved. 4. Delete your branch after your merge request is approved.
### Manage Hotfixes ### Manage Hotfixes
We treat a hotfix the same as other topic branches; see the instruction for [creating a new feature](#create-a-new-feature). We treat a hotfix the same as other topic branches; see the instruction for [creating a new feature](#create-a-new-feature).
### Undo Mistakes ### Undo Mistakes
TODO. TODO.
## Release Types ## Release Types
@ -86,29 +75,27 @@ Releases should be of the following types:
**Alpha:** Intended for internal use. These are early-stage versions that might have incomplete features or known bugs. They serve as the initial testing phase for new functionalities. **Alpha:** Intended for internal use. These are early-stage versions that might have incomplete features or known bugs. They serve as the initial testing phase for new functionalities.
**Beta:** Think of these as our MVP (Minimum Viable Product) versions. They are more polished than alpha versions, better tested, but might still have a few edges to smooth out. **Beta:** Think of these as our MVP (Minimum Viable Product) versions. They are more polished than alpha versions, better tested, but might still have a few edges to smooth out.
**Full Releases (v1, v2, ...):** The polished and full-featured versions, all set and stable. **Full Releases (v1, v2, ...):** The polished and full-featured versions, all set and stable.
We can also group them by pre-release (alpha, beta) and full release (v1, v2, ...). We can also group them by pre-release (alpha, beta) and full release (v1, v2, ...).
### Manage Releases ### Manage Releases
You must automate the process of creating releases and publishing them to repository servers. But triggering the release action should be done manually by the project's maintainer(s), whether by running a script locally or using CI services like GitHub Actions. You must automate the process of creating releases and publishing them to repository servers. But triggering the release action should be done manually by the project's maintainer(s), whether by running a script locally or using CI services like GitHub Actions.
By triggering a release, a script will: By triggering a release, a script will:
1. Decide on a version name based on the commits history since the last release 1. Decide on a version name based on the commits history since the last release
2. Update the changelog file 2. Update the changelog file
3. Update the code with the new version name and the local dependencies in monorepos. 3. Update the code with the new version name and the local dependencies in monorepos.
4. Run tests and build the software/packages to make sure everything works well 4. Run tests and build the software/packages to make sure everything works well
5. Commit changes on the trunk 5. Commit changes on the trunk
6. Create a tag off the trunk with the new version name 6. Create a tag off the trunk with the new version name
7. Push the trunk and the new tag to the remote repository 7. Push the trunk and the new tag to the remote repository
8. Publish packages to repository servers. 8. Publish packages to repository servers.
## Limitations ## Limitations
### Parallel release branches are not supported. ### Parallel release branches are not supported.
Developing multiple versions is not supported in this strategy; as a consequence, you will not be able to release a patch for older major and minor versions, so keep in mind to avoid introducing breaking changes as far as possible. Developing multiple versions is not supported in this strategy; as a consequence, you will not be able to release a patch for older major and minor versions, so keep in mind to avoid introducing breaking changes as far as possible.