Post-Chez 10 Distro & Release Considerations

Chez Scheme

Yes, that's correct, for now. I imagine that Racket's copy of Chez Scheme will be more conventionally vendored and aligned with Chez Scheme releases one day, but I don't think we're ready to move to that mode in the near future.

Zuo

The v1.8 and v1.9 tags are meant to count as releases, and the intent is to bump the version and create a new release tag whenever there's a change that some script might depend on (even if that's not an API change). I think we can commit to treating Zuo in the Racket repo as conventionally vendored.

Repository management

For repo syncing, I use git format-patch and git am. In one direction, git am needs --directory, and in the other direction, I remove an unwanted directory prefix with search and replace on the patch text. Sometimes, I use git subtree to first narrow patches to a particular subdirectory, but that's needed less and less, since patches now more often go from Chez Scheme to Racket.

For moving from Racket to Chez Scheme specifically with git subtree, I clone the whole Racket repo to a fresh checkout, use git subtree split --onto d41b86cc04 -P racket/src/ChezScheme there, use git reset --hard with the commit reported by git subtree, and then git format-patch followed by a suitable subtree commit to get patches up to that commit. (The commit d41b86cc04 is a more or less arbitrary choice — new enough to speed things along, but old enough to give me lots of context.)

When I move patches from one side to other, I adjust the release message to, say, add or remove a "Chez Scheme:" prefix, refer to a repo-specific commit, or fix a mistake noticed too late in the original commit message. Adding that Co-authored-by: was an example of fixing a release message (also noted in https://github.com/cisco/ChezScheme/commit/822d815965da538faade8a5508c54b4bd8497d1a).

1 Like