We release logs are recorded on [✨ CHANGELOG](https://github.com/OpenIMSDK/Open-IM-Server/blob/main/CHANGELOG/CHANGELOG.md)
This release is only possible thanks to **all** the support of some **awesome people**!
This release is only possible thanks to **all** the support of some **awesome people**!
Want to be one of them?
**Wantto be one of them 😘?**
Contributions to this project are welcome! Please see [CONTRIBUTING.md](https://github.com/OpenIMSDK/Open-IM-Server/blob/main/CONTRIBUTING.md) for details.
Contributions to this project are welcome! Please see [CONTRIBUTING.md](https://github.com/OpenIMSDK/Open-IM-Server/blob/main/CONTRIBUTING.md) for details.
@ -51,15 +51,15 @@ Open-IM-Server is not a standalone product and does not include account registra
1. Clone the project
1. Clone the project
```
```bash
clone https://github.com/OpenIMSDK/Open-IM-Server
# choose what you need
cd Open-IM-Server
BRANCH=release-v3.0
git checkout release-v3.0 #or other release branch
git clone -b $BRANCH https://github.com/OpenIMSDK/Open-IM-Server openim && export openim=$(pwd)/openim && cd $openim && make build
```
```
1. Modify .env
2. Modify .env
```
```bash
USER=root #no need to modify
USER=root #no need to modify
PASSWORD=openIM123 #A combination of 8 or more numbers and letters, this password applies to redis, mysql, mongo, as well as accessSecret in config/config.yaml
PASSWORD=openIM123 #A combination of 8 or more numbers and letters, this password applies to redis, mysql, mongo, as well as accessSecret in config/config.yaml
ENDPOINT=http://127.0.0.1:10005 #minio's external service IP and port, or use the domain name storage.xx.xx, the app must be able to access this IP and port or domain,
ENDPOINT=http://127.0.0.1:10005 #minio's external service IP and port, or use the domain name storage.xx.xx, the app must be able to access this IP and port or domain,
@ -67,20 +67,19 @@ API_URL=http://127.0.0.1:10002/object/ #the app must be able to access this IP a
DATA_DIR=./ #designate large disk directory
DATA_DIR=./ #designate large disk directory
```
```
1. Deploy and start
3. Deploy and start
Note: This command can only be executed once. It will modify the component passwords in docker-compose based on the PASSWORD variable in .env, and modify the component passwords in config/config.yaml. If the password in .env changes, you need to first execute docker-compose down; rm components -rf and then execute this command.
> **Note**
> This command can only be executed once. It will modify the component passwords in docker-compose based on the PASSWORD variable in .env, and modify the component passwords in config/config.yaml. If the password in .env changes, you need to first execute docker-compose down; rm components -rf and then execute this command.
Our project, OpenIM, follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) standards.
> Chinese translation: [Conventional Commits: A Specification Making Commit Logs More Human and Machine-friendly](https://tool.lu/en_US/article/2ac/preview)
In addition to adhering to these standards, we encourage all contributors to the OpenIM project to ensure that their commit messages are clear and descriptive. This helps in maintaining a clean and meaningful project history. Each commit message should succinctly describe the changes made and, where necessary, the reasoning behind those changes.
To facilitate a streamlined process, we also recommend using appropriate commit type based on Conventional Commits guidelines such as `fix:` for bug fixes, `feat:` for new features, and so forth. Understanding and using these conventions helps in generating automatic release notes, making versioning easier, and improving overall readability of commit history.
Error codes are one of the important means for users to locate and solve problems. When an application encounters an exception, users can quickly locate and resolve the problem based on the error code and the description and solution of the error code in the documentation.
### Error Code Naming Standards
- Follow CamelCase notation;
- Error codes are divided into two levels. For example, `InvalidParameter.BindError`, separated by a `.`. The first-level error code is platform-level, and the second-level error code is resource-level, which can be customized according to the scenario;
- The second-level error code can only use English letters or numbers ([a-zA-Z0-9]), and should use standard English word spelling, standard abbreviations, RFC term abbreviations, etc.;
- The error code should avoid multiple definitions of the same semantics, for example: `InvalidParameter.ErrorBind`, `InvalidParameter.BindError`.
- The unified log package `github.com/OpenIMSDK/Open-IM-Server/internal/pkg/log` should be used for all logging;
- Use structured logging formats: `log.Infow`, `log.Warnw`, `log.Errorw`, etc. For example: `log.Infow("Update post function called")`;
- All logs should start with an uppercase letter and should not end with a `.`. For example: `log.Infow("Update post function called")`;
- Use past tense. For example, use `Could not delete B` instead of `Cannot delete B`;
- Adhere to log level standards:
- Debug level logs use `log.Debugw`;
- Info level logs use `log.Infow`;
- Warning level logs use `log.Warnw`;
- Error level logs use `log.Errorw`;
- Panic level logs use `log.Panicw`;
- Fatal level logs use `log.Fatalw`.
- Log settings:
- Development and test environments: The log level is set to `debug`, the log format can be set to `console` / `json` as needed, and caller is enabled;
- Production environment: The log level is set to `info`, the log format is set to `json`, and caller is enabled. (**Note**: In the early stages of going online, to facilitate troubleshooting, the log level can be set to `debug`)
- When logging, avoid outputting sensitive information, such as passwords, keys, etc.
- If you are calling a logging function in a function/method with a `context.Context` parameter, it is recommended to use `log.L(ctx).Infow()` for logging.
Our project, OpenIM, follows the [Semantic Versioning 2.0.0](https://semver.org/lang/zh-CN/) standards.
## OpenIM version
OpenIM manages two primary branches: `main` and `release`. The project uses Semantic Versioning 2.0.0 to tag different versions of the software, each indicating a significant milestone in the software's development.
In the OpenIM repository, the versioning adheres to the `MAJOR.MINOR.PATCH` format, where:
- `MAJOR` version changes when there are incompatible changes to the API,
- `MINOR` version changes when features are added in a backward-compatible manner, and
- `PATCH` version changes when backward-compatible bugs are fixed.
## Milestones and Branching
When a significant milestone like v3.1.0 is achieved, a new branch `release-v3.1` is created. This branch contains all the code pertaining to this stable release. All bug fixes and features intended for the next version, v3.2.0, are merged into this branch.
The release of `PATCH` versions (Z in `X.Y.Z`) are driven by bug fixes, and these can be rolled out depending on the bug's priority or over a scheduled time. On the other hand, `MINOR` versions (Y in `X.Y.Z`) are released based on the project's roadmap, milestone completion, or on a scheduled timeline. Importantly, the API of minor versions is always backward-compatible.
## Dealing with Major Bugs
In the event of a major bug discovery, the fix would selectively be merged into the previous version (e.g., v3.1 or the `release-v3.1` branch), as well as into the `main` branch. This is to ensure that users relying on the older version can still receive important bug fixes, while also keeping the main branch updated.
It's worth noting that a robust testing regime should be in place to ensure the integrity of all branches at any given time. Automated tests and code review sessions are crucial components of maintaining a healthy codebase.
To summarize, OpenIM's approach to branch management and versioning ensures a balance between introducing new features, fixing bugs, and maintaining backward compatibility. This strategy is vital for managing user expectations, supporting older versions, and paving the way for the project's continuous growth.
## Git Workflow Example
To put the above principles into practice, here's a Git workflow example that you might follow when working on a bug fix:
```
bashCopy code# Checkout the branch for the version that needs the bug fix
git checkout release-v3.1
# Create a new branch for the bug fix
git checkout -b bug/bug-name
# ... Make changes, commit your work ...
# Push the branch to your remote repository
git push origin bug/bug-name
# After the pull request is merged into the release-v3.1 branch,
# checkout and update your main branch
git checkout main
git pull origin main
# Merge or rebase the changes from release-v3.1 into main
git merge release-v3.1
# Push the updates to the main branch
git push origin main
```
Remember, communication with your team is key throughout this process, keeping everyone up-to-date with the changes being made.
wangchuxiao
2 years ago