Tracking: prepare and manage release_v4.8.1 branch

[troncommons]

This issue is to coordinate the creation and tracking of the release_v4.8.1 branch from develop.

Branch Details

• Version: v4.8.1
• Branch to create: release_v4.8.1
• Base branch: develop

Tasks

• Create release_v4.8.1 branch from develop
• Push final PRs to release_v4.8.1 (e.g., version bump, changelog, fixes, features)
• Perform QA and testing on release_v4.8.1
• Merge release_v4.8.1 back to master when testing is complete
• Tag GreatVoyage-v4.8.1(Democritus) on master and release
• Merge master back to develop (if applicable)

Notes

• Once the release_v4.8.1 branch is created, it will act as the staging area for all final updates and fixes for this release.
• Any non-release-related changes should continue in develop.

PRs without Issue

• feat(net): optimize fetch inventory message processing logic #5895
• feat(doc): update readme for telegram groups and doc link #6364
• feat(config): sync config.conf with tron-deployment #6332
• feat(gradle): upgrade the maven publishing #6367
• fix(pb): protocol buffer file syntax compatibility issue #6386

[troncommons]

Hi, for the first task, we will create release_v4.8.1 branch from develop.
The different between develop and master could be find here.
Is the develop branch in a satisfactory state for the next release?
If there is any problem please list here.
If no, we’re planning to create the branch in two days.

[King31T]

Do final prs in task 2 mean those new prs planned to be in v4.8.1 after release_v4.8.1 is created? If not planned in v4.8.1, still merged into develop branch?

[troncommons]

Do final prs in task 2 mean those new prs planned to be in v4.8.1 after release_v4.8.1 is created? If not planned in v4.8.1, still merged into develop branch?

Yep, anything that’s not going into the next release should go to develop.

[GordonLtron]

The task can still be edit from develop after the states changes right? For example, a task planned to be developed in 4.8.1 but got delay; cannot meet the timeline.

[troncommons]

The task can still be edit from develop after the states changes right? For example, a task planned to be developed in 4.8.1 but got delay; cannot meet the timeline.

Yes, if the feature isn’t ready, it won’t be merged into the release branch. It should go back to the issue pool and wait for a future release.

[troncommons]

Hi, for the first task, we will create release_v4.8.1 branch from develop. The different between develop and master could be find here. Is the develop branch in a satisfactory state for the next release? If there is any problem please list here. If no, we’re planning to create the branch in two days.

If there are no further questions, the release_v4.8.1 branch will be created this afternoon.
Please raise any objections as soon as possible.

[jwrct]

Does this version already have a rough timeline?

[troncommons]

Does this version already have a rough timeline?

The development cycle for this version is tentatively set for June to August. We can tracking the development here .
If needed, we can adjust this timeline.

[lxcmyf]

@troncommons
Is there any significant update worth looking forward to in this version?