msb-public
/
Open-IM-Server
mirror of https://github.com/OpenIMSDK/Open-IM-Server
2
0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bde3d98d0f'
${ noResults }
Open-IM-Server/docs/conversions/version.md

8.4 KiB
Raw Blame History

OpenIM Branch Management and Versioning: A Blueprint for High-Grade Software Development

📚 OpenIM TOC

At OpenIM, we acknowledge the profound impact of implementing a robust and efficient version management system, hence we abide by the established standards of Semantic Versioning 2.0.0.

Our software blueprint orchestrates a tripartite version management system that integrates the main branch, the release branch, and tag management. These constituents operate in synchrony to preserve the reliability and traceability of our software across various stages of development.

Unfolding the Mechanism of OpenIM Version Maintenance

Our version maintenance protocol revolves around two primary branches, namely: main and release. We resort to Semantic Versioning 2.0.0 for marking distinctive versions of our software, representing substantial milestones in its evolution.

In the OpenIM repository, version identification strictly complies with the MAJOR.MINOR.PATCH protocol. Herein:

  • The MAJOR version indicates a shift arising from incompatible changes to the API.
  • The MINOR version suggests the addition of features in a backward-compatible manner.
  • The PATCH version flags backward-compatible bug fixes.

Main Branch: The Heart of OpenIM Development

The main branch is the operational heart of our development process. Housing the most recent and advanced features, this branch serves as the nerve center for all enhancements and updates. It encapsulates the freshest, though possibly unstable, facets of the software. Visit our main branch here.

Release Branch: The Beacon of Stability

For every major release, we curate a corresponding release branch, e.g., release-v3.1. This branch symbolizes an embodiment of stability and ensures an updated version of the software, providing a dependable option for users favoring stability over nascent, yet possibly unstable, features. Visit the release-v3.1 branch here.

Tag Management: The Cornerstone of Version Control

In OpenIM's version control system, the role of tags stands paramount. Owing to their immutable nature, tags can be effectively utilized to retrieve a specific version of the software. Explore our library of tags here.

Our Docker image versions are intimately entwined with these tripartite components. For instance, a Docker image tag may correspond to ghcr.io/openimsdk/openim-server:v3.1.0, a release to ghcr.io/openimsdk/openim-server:release-v3.0, and the main branch to ghcr.io/openimsdk/openim-server:main or ghcr.io/openimsdk/openim-server:latest.

To further clarify, the semantics of our version numbers are as follows:

  • Revision version number: This represents bug fixes or code optimizations. Typically, it entails no new feature additions and ensures backward compatibility.
  • Build version number: Auto-generated by the system, each code submission prompts an automatic increment by 1.
  • Version modifiers: These hint at the software's development stage and stability. Some commonly used modifiers are alpha, beta, rc, ga, r/release/or nothing, and lts.
    • alpha: An internal testing version with numerous bugs, typically used for communication among developers.
    • beta: A test version with numerous bugs, generally used for testing by eager community members, who provide feedback to the developers.
    • rc: Release candidate, which is 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 discovered in this version.

Whenever a project undergoes a partial functional addition, the minor version number increments by 1, resetting the revision version number to 0. In contrast, any major project overhaul results in an increment by 1 in the major version number. The build number, typically auto-generated during the compilation process, only requires format definition, thereby eliminating manual control.

Release Management: A Guided Tour

Our GitHub repository at https://github.com/OpenIMSDK/Open-IM-Server/releases associates a release with each tag, with a distinction between Pre-release and Latest, determined by the branch source. Every significant feature launch prompts the issue of a release branch, such as release-v3.2, as a beacon of stability and Latest release.

Pre-releases correspond to releases from the main branch, denoting tags with Version modifiers such as v3.2.1-beta.0, v3.2.1-rc.1, etc. If you are seeking the most recent, albeit possibly unstable, release with new features, these tags, originating from the latest main branch code, are your go-to.

Conversely, if stability is your primary concern, you should opt for the release tagged Latest, denoted by tags without Version modifiers, such as v3.2.1, v3.2.2 etc. These tags are linked to the latest stable maintenance branch, like release-v3.2.

Milestones, Branching, and Addressing Major Bugs

About:

We create a new branch, such as release-v3.1, for each significant milestone (e.g., v3.1.0), housing all relevant code for that release. All enhancements and bug fixes targeting the subsequent version (e.g., v3.2.0) are integrated into this branch.

PATCH versions (represented by Z in X.Y.Z) are primarily propelled by bug fixes, and their release may be either priority-driven or scheduled. In contrast, MINOR versions (represented by Y in X.Y.Z) are contingent upon the project's roadmap, milestone completion, or a pre-established timeline, always maintaining backward-compatible APIs.

When dealing with major bugs, we selectively merge the fix into the affected version (e.g., v3.1 or the release-v3.1 branch), as well as the main branch. This dual pronged strategy ensures that users on older versions receive crucial bug fixes, while also keeping the main branch updated.

We reinforce our approach to branch management and versioning with stringent testing protocols. Automated tests and code review sessions form vital components of maintaining a robust and reliable codebase.

Applying Principles: A Git Workflow Example

The workflow to address a bug fix might follow these steps:

bashCopy codebashCopy 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

Throughout this process, active communication within the team is pivotal to maintaining transparency and consensus on changes.

Docker Images Version Management

For more details on managing Docker image versions, visit OpenIM Docker Images Administration.