package manager: resolve and lock two majors of one package

orion commented

2026-10-12 08:24:56 +00:00

Collaborator

Context

Slice 1 of 3 of #28 (two majors of one package in one graph). The resolver and the lock treat the package name as the identity, so two majors of acme/json (for example ^1.2 wanted by one dependency and ^2.0 by another) fail with a conflict today.

Design

docs/design/PROJECT.md section 6a ("One version per package in a graph, not one per major"): the resolver's package becomes (name, major). CONCEPT "Packages and the Supply Chain" already promises one version per major, so this lifts a restriction and breaks nothing that resolves today.

Scope

compiler/src/package/resolve.trb (and index.trb where it keys by name): solver package key (name, major); a requirement ^1.2 or >=1.2 <2 selects the key of its major; a requirement that spans majors (>=1 <3) is split per major as alternatives, preferring the highest major only where both satisfy, so existing graphs resolve exactly as before.
compiler/src/package/lock.trb: package lines may repeat a name with different majors; the order stays deterministic (name, then version); reading and torb lock --check accept it. Single-major locks are byte-identical to today.
Explanations name acme/json 1.x/2.x where the major matters.

Acceptance criteria

Resolver unit test: a graph where a needs acme/json ^1 and b needs acme/json ^2 resolves to one version of each major.
A graph with only one major per package resolves and locks byte-identically to before (existing resolver and lock tests unchanged).
Round trip: write then read a lock with two majors of one package; torb lock --check passes on it.
Conflict inside one major (^1.2 vs <1.1) still fails with an explanation naming the major.

Seed impact

None: no syntax, native, driver flag or std name change. The lock format only gains a repeated name.

Dependencies

None. Size: one PR (feat(package): resolve and lock two majors of one package). Blocks the next slices.

## Context Slice 1 of 3 of #28 (two majors of one package in one graph). The resolver and the lock treat the package name as the identity, so two majors of `acme/json` (for example `^1.2` wanted by one dependency and `^2.0` by another) fail with a conflict today. ## Design [docs/design/PROJECT.md section 6a](https://git.torb.dev/torbscript/language/src/branch/main/docs/design/PROJECT.md#6a-requirements-and-resolution) ("One version per package in a graph, not one per major"): the resolver's package becomes `(name, major)`. CONCEPT "Packages and the Supply Chain" already promises one version per major, so this lifts a restriction and breaks nothing that resolves today. ## Scope - `compiler/src/package/resolve.trb` (and `index.trb` where it keys by name): solver package key `(name, major)`; a requirement `^1.2` or `>=1.2 <2` selects the key of its major; a requirement that spans majors (`>=1 <3`) is split per major as alternatives, preferring the highest major only where both satisfy, so existing graphs resolve exactly as before. - `compiler/src/package/lock.trb`: `package` lines may repeat a name with different majors; the order stays deterministic (name, then version); reading and `torb lock --check` accept it. Single-major locks are byte-identical to today. - Explanations name `acme/json 1.x`/`2.x` where the major matters. ## Acceptance criteria - [ ] Resolver unit test: a graph where `a` needs `acme/json ^1` and `b` needs `acme/json ^2` resolves to one version of each major. - [ ] A graph with only one major per package resolves and locks byte-identically to before (existing resolver and lock tests unchanged). - [ ] Round trip: write then read a lock with two majors of one package; `torb lock --check` passes on it. - [ ] Conflict inside one major (`^1.2` vs `<1.1`) still fails with an explanation naming the major. ## Seed impact None: no syntax, native, driver flag or std name change. The lock format only gains a repeated name. ## Dependencies None. Size: one PR (`feat(package): resolve and lock two majors of one package`). Blocks the next slices.

orion added the

loop

label

2026-10-12 08:24:56 +00:00

orion referenced this issue

2026-10-12 08:24:57 +00:00

package manager: load two majors of one package side by side #324

orion added the

ready

label

2026-10-12 08:24:57 +00:00

orion commented

2026-10-12 08:25:05 +00:00

Author

Collaborator

[loop:torbscript] refine: split out of #28 as slice 1 of 3; goal, acceptance criteria, design link and seed impact stated, one PR. label ready, next: implement

orion referenced this issue

2026-10-12 08:25:05 +00:00

package manager: load two majors of one package side by side #324

orion referenced this issue

2026-10-12 08:25:06 +00:00

package manager: two majors of one package in one graph #28

orion commented

2026-10-12 08:25:58 +00:00

Author

Collaborator

[loop:torbscript] claim implement by session:loop-torbscript-20261012 until 2026-10-12T14:25Z

orion commented

2026-10-12 11:04:03 +00:00

Author

Collaborator

[loop:torbscript] release: implement worker died on the account session limit before pushing a branch (resets 13:00 Berlin); respawning

orion commented

2026-10-12 11:04:04 +00:00

Author

Collaborator

[loop:torbscript] claim implement by session:loop-torbscript-20261012 until 2026-10-12T17:04Z

orion referenced this issue from a commit

2026-10-12 11:19:17 +00:00

feat(package): resolve and lock two majors of one package

orion referenced this issue from a pull request that will close it,

2026-10-12 11:19:52 +00:00

feat(package): resolve and lock two majors of one package #328

orion referenced this issue from a commit

2026-10-12 11:19:54 +00:00

feat(package): resolve and lock two majors of one package

orion referenced this issue from a commit

2026-10-12 11:23:15 +00:00

feat(package): resolve and lock two majors of one package

orion referenced this issue from a commit

2026-10-12 12:12:28 +00:00

feat(package): resolve and lock two majors of one package

orion commented

2026-10-12 13:12:19 +00:00

Author

Collaborator

[loop:torbscript] release: implement worker terminated after opening PR #328 (head 6f592335): tier A (linux-x64) red, PR not mergeable against main after #329; respawning

[loop:torbscript] release: implement worker terminated after opening PR #328 (head 6f592335): tier A (linux-x64) red, PR not mergeable against main after #329; respawning

orion commented

2026-10-12 13:12:19 +00:00

Author

Collaborator

[loop:torbscript] claim implement by session:loop-torbscript-20261012 until 2026-10-12T19:12Z

orion referenced this issue from a commit

2026-10-12 13:16:04 +00:00

feat(package): resolve and lock two majors of one package