nacos-group / nacos-group/nacos-sdk-python
📢 Branch restructuring: master branch will switch to 3.x codebase
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 471
- Forks
- 155
- PR merge metrics
- No merged PRs in 30d
Description
Background
Since the release of nacos-sdk-python 3.0.0, the v3 branch has gone through multiple iterations (3.0.0 → 3.0.1 → 3.0.2 → 3.0.3 → 3.0.4) and has become increasingly stable. With the Nacos 3.x ecosystem maturing, it's time to make v3 the primary development line for this SDK.
What's Changing
We will be restructuring the branches as follows:
| Branch | Before | After |
|---|---|---|
master |
v2.x codebase | v3.x codebase |
feature/v2 |
— | v2.x codebase (maintenance mode) |
- The
masterbranch will be replaced with the current v3 codebase (previously onfeature/v3). - The current v2 code on
masterwill be moved to thefeature/v2branch and continue to be maintained.
Impact
For 3.x developers
No action needed. After the switch, you can track the master branch directly to get the latest v3 updates.
For 2.x developers
Please switch your dependency tracking to the feature/v2 branch:
git fetch origin
git checkout feature/v2
The 2.x line will continue to receive critical bug fixes, but new features will only be developed on v3 (master).
For contributors
- New feature PRs should target the
masterbranch (3.x). - 2.x bug fix PRs should target the
feature/v2branch. - If you have local branches based on the old
master, please rebase ontofeature/v2if they are 2.x-related.
Timeline
The branch switch is planned for [具体日期]. We will update this issue once the migration is complete.
2.x Maintenance Policy
The feature/v2 branch will remain in maintenance mode for the foreseeable future. We will continue to:
- ✅ Accept critical bug fixes
- ✅ Address security vulnerabilities
- ❌ No new feature development
We appreciate everyone's patience during this transition. If you have any questions or concerns, please leave a comment below.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. Review the repository branches master, feature/v2, and feature/v3, then verify the planned branch mapping and contributor guidance; completion means v3 is on master and v2 is preserved on feature/v2.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, python
- Domain
- release
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100