Skip to content
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.

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

docs: clarify expression #198

Merged
merged 1 commit into from
Mar 7, 2025
Merged
Changes from all commits
Commits
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
12 changes: 8 additions & 4 deletions doc/llpkgstore.md
Original file line number Diff line number Diff line change
Expand Up @@ -300,14 +300,18 @@ Otherwise, start with `v0.1.0`, until it releases a stable version. ([email protected]

#### Problem

As the previous example shows, non-breaking changes introduced by upstream C library updates should be indicated by llpkg's **MINOR** update. But there's one exception:

| C Library Version | llpkg Version | Issue |
|--------------------|---------------|-------|
| 1.5.1 | `1.0.0` | Initial release |
| 1.5.1 (llpkg fix) | `1.0.1` | Patch increment |
| 1.6 | `1.1.0` | Minor increment |
| 1.5.2 | ? | Conflict: `1.1.0` already allocated |

If we increment PATCH to `1.0.2` to represent `[email protected]`:
In this case, upstream releases `1.5.2` targeting older `1.5.x` series, which should have been represented by **MINOR** update. However, we cannot simply assign `1.2.0` to `1.5.2`, because in that case, `1.6` would be less prioritized than `1.5.2` (breaking version ordering). We can't assign `1.1.0` either, because `1.1.0` is already allocated to `1.6`.

The solution that keeps the version ordering is to update llpkg's **PATCH**. If we increment PATCH to `1.0.2` to represent `[email protected]`:

| C Library Version | llpkg Version | Issue |
|--------------------|---------------|-------|
Expand All @@ -317,7 +321,7 @@ If we increment PATCH to `1.0.2` to represent `[email protected]`:
| 1.5.2 | `1.0.2` | Conflict: `1.1.0` already allocated |
| 1.5.1 (llpkg fix 2) | `1.0.3` | Patch increment |

`[email protected]` > `[email protected]` maps to `[email protected]` < `[email protected]` (breaking version ordering), which causes MVS to prioritize `1.0.3` (lower priority upstream version) over `1.0.2`.
`[email protected]` > `[email protected]` maps to `[email protected]` < `[email protected]`, which causes MVS to prioritize `1.0.3` (lower priority upstream version) over `1.0.2`. llpkg's self patching for previous minor versions breaks the version ordering!

#### Conflict resolution rule

Expand Down Expand Up @@ -418,10 +422,10 @@ Post-processing GitHub Action will tag the commit following the [Version Tag Rul

1. Create an issue to discuss the package that requires maintenance.
2. The maintainer creates a label in the format `branch:release-branch.{CLibraryName}/{MappedVersion}` and adds it to the issue if the package needs maintenance.
3. A GitHub Action is triggered when the label is created. It searches for issues with the specified label and determines whether a branch should be created based on the [Branch Maintenance Strategy](#branch-maintenance-strategy).
3. A GitHub Action is triggered when the label is created. It determines whether a branch should be created based on the [Branch Maintenance Strategy](#branch-maintenance-strategy).
4. Open a pull request (PR) for maintenance. The maintainer **SHOULD** merge the PR with the commit message `fixed {IssueID}` to close the related issue.
5. When issues labeled with `branch:release-branch.` are closed, we need to determine whether to remove the branch. In the following case, the branch and label can be safely removed:
- No commit contains `fix* {ThisIssueID}`.(* means the commit starting with `fix` prefix)
- No associated PR with commit containing `fix* {ThisIssueID}`.(* means the commit starting with `fix` prefix)

## llpkg.goplus.org

Expand Down
Loading