@ -6,21 +6,36 @@ OpenIM, the open source project, employs a comprehensive version management syst
## Main Branch
The `main` branch is where all the latest code resides. It's the hub of activity, embodying all the cutting-edge features that are currently being developed or updated. However, since it's subject to frequent changes and updates, it may not always represent the most stable version of the software. Access the `main` branch [here](https://github.com/openimsdk/openim-server/tree/main).
The `main` branch is where all the latest code resides. It's the hub of activity, embodying all the cutting-edge features that are currently being developed or updated. However, since it's subject to frequent changes and updates, it may not always represent the most stable version of the software. Access the `main` branch [here](https://github.com/OpenIMSDK/Open-IM-Server/tree/main).
## Release Branch
On the other hand, we have the `release` branch. For instance, in the context of version 3.1, we maintain a `release-v3.1` branch. Unlike the `main` branch, the release branch is designed to be a continuously stable and updated version of the software. This provides a reliable option for users who prefer stability over the latest, but potentially unstable, features. Access the `release-v3.1` branch [here](https://github.com/openimsdk/openim-server/tree/release-v3.1).
On the other hand, we have the `release` branch. For instance, in the context of version 3.1, we maintain a `release-v3.1` branch. Unlike the `main` branch, the release branch is designed to be a continuously stable and updated version of the software. This provides a reliable option for users who prefer stability over the latest, but potentially unstable, features. Access the `release-v3.1` branch [here](https://github.com/OpenIMSDK/Open-IM-Server/tree/release-v3.1).
## Tag Management
Finally, there's `tag` management. Despite having both `main` and `release` branches, `tag` serves a crucial role. Tags are immutable, i.e., they remain unchanged once created. Therefore, if you need a specific version of the software, you can use the corresponding tag. Check out the available tags [here](https://github.com/openimsdk/openim-server/tags).
In addition to the `main` and `release` branches, `tag` also plays a pivotal role in version control. Tags are immutable, meaning once they're created, they remain unchanged. Therefore, if you need a specific version of the software, you can use the corresponding tag. All of our available tags can be viewed [here](https://github.com/OpenIMSDK/Open-IM-Server/tags).
Moreover, our Docker image versions are closely tied with these three components. For instance, a tag might correspond to the Docker image `ghcr.io/openimsdk/openim-server:v3.1.0`, a release would be `ghcr.io/openimsdk/openim-server:release-v3.0`, and the main branch might be represented as `ghcr.io/openimsdk/openim-server:main` or `ghcr.io/openimsdk/openim-server:latest`.
Moreover, our Docker image versions are closely tied with these three components. For example, a tag might correspond to the Docker image `ghcr.io/openimsdk/openim-server:v3.1.0`, a release might be represented as `ghcr.io/openimsdk/openim-server:release-v3.0`, and the main branch could be represented as `ghcr.io/openimsdk/openim-server:main` or `ghcr.io/openimsdk/openim-server:latest`.
To find out more, or to contribute to our project, please visit our GitHub repository at [OpenIM Server](https://github.com/openimsdk/openim-server).
Here is the specification of our version numbers:
We believe that this approach offers a balanced blend of innovation and stability, enabling us to provide the best possible software to our users.
- **Revision version number**: The third digit of the version number, representing bug fixes or code optimizations, usually no new features are added and it is backward compatible with older versions.
- **Build version number**: Usually automatically generated by the system, every code submission will result in an automatic increment by 1.
- Version modifiers
: These can represent the development stage and stability of the software. Common ones include:
- `alpha`: An internal testing version with many bugs, generally used for communication among developers.
- `beta`: A test version with many bugs, generally used for testing by eager community members, who provide feedback to the developers.
- `rc`: Release candidate, to be released as the official version, it's the last test version before the official version.
- `ga`: General Availability, the first stable release.
- `r/release/or nothing`: The final release version, intended for general users.
- `lts`: Long Term Support, the official will specify the maintenance year for this version and will fix all bugs found in this version.
When adding partial functions to the project, the minor version number increases by 1, and the revision version number resets to 0. When there are major changes in the project, the major version number increases by 1. The build number is generally automatically generated by the compiler during the compilation process, only the format needs to be defined, and it does not need to be manually controlled.
pluto
2 years ago
committed by
GitHub