release: v1.1.0 #70
No reviewers
Labels
No labels
area:defold
area:docs
area:infra
area:protocol
area:testing
kind:bug
kind:chore
phase:breadth
phase:core
phase:hardening
phase:slice
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
yuris/spacetimedb-defold!70
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "release/v1.1.0"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Final Phase 5 item of the v1.1.0 milestone (#59).
game.project'sversiongoes1.0.0→1.1.0, and the threev1.0.0URLs inREADME.mdbecomev1.1.0: the archive link in the Install block, theprivate-repo token example, and the HTML5 patch-fetch.
The tag those URLs name does not exist until this merges, which is fine —
html5-conformance.shappliespatches/from the working tree, not from the URL,so conformance does not depend on it.
Verification
The archive gate flagged this bump as the one blocking item left, and noted the
archive verification should be re-run against the tag's own artifact afterwards,
since this changes two shipped members (
game.project,README.md). The filelist is unaffected, so the composition,
.gitattributescoverage andrequire-resolution results carry over.
One harness observation, not a blocker
html5-conformance.shreturnedFAILonce on this branch and then passed fourtimes in a row (28/29/28s against a 120s timeout). I did not capture the frames,
so I cannot attribute it; recorded on #52, which exists for exactly this and asks
for a frame capture next time. Explicitly ruled out: it is not PHASE6 pushing the
per-load budget, since the passing runs sit at ~4× headroom and a timeout emits
its own distinct message.
dev/is export-ignored, so this is harnessreliability, not shipped behaviour — and it is the standing reason #16's
continue-on-errorstays on the HTML5 CI step.