Repository navigation
Changes in main that downstream projects need to know about: how do they find out? #905
Description
Projects that build on nxnative, like NX2Apple, take main in with every update. We read the commits, but we cannot reliably tell which ones matter to us. nxnative has no releases and no tags, so there is no place that says what changed for a front end. Three kinds of changes are hard to see:
- Changes that break something that already exists. Since
7c23cc0("backslashes separate path components", PR fs: backslash path separators and 8-byte aligned file handles #513) a save that an older host wrote as\savedata0.binis not found, because the host now looks forsavedata0.bin. Link's Awakening (01006BB00C6F0000) shows "New game" for every file, and the saves are still in the folder. A patch that copies them is in Games keep the saves an older engine named \savedata0.bin (patch 0056) LNPANDY/NX2Apple#461. The shader chain is another case: a bump moves it, and every game built before it has to be built again. - Changes to an interface a front end uses. A new or changed environment variable, script argument, JSON progress event or field, manifest or profile field, file or output path.
- New functions a front end could offer. A new setting, a new kind of input (a merged NSP, a folder without
prod.keys), a new kind of game (Switch 2), a new requirement.
The last update was 53 commits. We cannot tell for sure which of them touch these three.
Would you add a short convention? For example a section "For front ends" in the pull request description, with one line for each of the three kinds when a change has one, and the same line in the squash commit message. Then git log --grep finds them for everyone who follows main. If you prefer another place, such as a docs/CHANGES.md, that works for us too. We can also help to write the list for commits that are already in. Our own reading of the 53 commits is a start.
Activity
[-]Where do changes that affect existing saves and builds get announced?[/-][+]Changes in main that break existing saves, caches or builds: how do downstream projects find out?[/+][-]Changes in main that break existing saves, caches or builds: how do downstream projects find out?[/-][+]Changes in main that downstream projects need to know about: how do they find out?[/+]seedds commentedon Nov 4, 2026
Done in abd7014 and ae03116, thanks for the proposal.
Finding changes. Following main has the git commands for what git can show: the contract, the NSP script's options, the environment switches and the shader chain. What git cannot show gets a line in the commit message, from here on:
Each line starts with
Front-ends: break:,interface:ornew:. Chain changes get no line, because there were 47 in a week andgit log -- dm/gfx/nvn/dmsh_chain.hand theshaders_staleevent already show them. There is nodocs/CHANGES.md, and older commits are not backfilled, so your reading of the 53 commits stays useful on your side. A line is what the author knows, so a missing line is no proof that nothing changed:7c23cc0would have had none.The saves. A host with abd7014 renames these saves itself at mount, on the Mac and the iPhone, so nxnative's own players get the fix too. On Link's Awakening on the Mac, a save renamed to the old form shows New Game for every file without the fix, and File 1 with it. It also works through a cloud folder. It has not been run on an iPhone.
For NX2Apple#461: its patch is not needed once your engine pin includes abd7014, and the diagnosis there is credited in that commit. The behaviour differs from the patch in two ways:
7c23cc0can no longer read a renamed save.\diranddirmerge. An entry whose new name is taken stays under its old name, with a log line at each mount.More in Saves named before backslash paths.
Front ends can follow main: docs/frontends.md says what git shows, an…
Front ends can follow main: docs/frontends.md says what git shows, an…