Skip to content

[INTERNAL] Guidelines: Document up-porting to main #1181

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 3, 2025
Merged

[INTERNAL] Guidelines: Document up-porting to main #1181

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions docs/Guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,11 +50,11 @@ Fixes: #45
```

## Work on Release Branches
Major releases are typically prepared on dedicated branches like `next`.
Currently, the `v4` branch is the latest stable release, while the next major release (`v5`) is being developed on the `main` branch.

There are some things to be aware of when working on these branches.
There are some things to be aware of when working across these branches.

### Implementing Changes in Multiple Code Lines
While working on a new major release (e.g. `5.0.0`), any fixes or new features implemented on the **current** (main) code line (e.g. 4.x) should be cherry-picked as `[INTERNAL]` to the dedicated (pre-)release branch (typically `next`). This is to prevent changes declared as `[FEATURE]` or `[FIX]` from appearing in the changelog twice, which can be confusing since the new major version has not yet been released and should naturally contain any fixes or features released in any of the preceding releases. Listing them twice might confuse users. Note that our changelog is generated based on all tags of the repository, independent of the currently checked out branch (also see [git-chglog/issues/123](https://github.com/git-chglog/git-chglog/issues/123)).
### Implementing Fixes Across `v4` and `main` Branches
During the development period until the first `v5` release, fixes should be implemented on the **`v4` branch first**, and then up-ported to the **`main` branch**. This ensures that the stable release receives fixes promptly while maintaining consistency across both code lines.

However, once a new major release becomes **current** (i.e. "main", not a pre-release), any changes applied to multiple code lines should be cherry picked with the original prefix, so that they appear for multiple versions in the changelog.
When up-porting fixes from `v4` to `main`, note that the commit message guidelines differ between branches. The `v4` branch uses the OpenUI5-style commit message format (as documented above), while the `main` branch uses conventional commits. Please refer to the [Guidelines.md file on the main branch](https://github.com/UI5/cli/blob/main/docs/Guidelines.md) for the appropriate commit message format when working there.