# Post-Chez 10 Distro & Release Considerations

**URL:** https://racket.discourse.group/t/post-chez-10-distro-release-considerations/2739
**Category:** Distro Packagers
**Tags:** question, chez, zuo, internals, build
**Created:** [February 24, 2024, 6:06pm UTC](https://racket.discourse.group/t/post-chez-10-distro-release-considerations/2739 "2024-02-24T18:06:50Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)
#### Post date: [February 26, 2024, 1:57pm UTC](https://racket.discourse.group/t/post-chez-10-distro-release-considerations/2739/3 "2024-02-26T13:57:10Z")

</div>

## Chez Scheme

> [@LiberalArtist](#):
>
> My understanding is that there is no plan to align the Chez Scheme and Racket release cycles, and a given released version of Racket will continue to depend on a specific pre-release version of Chez Scheme (except perhaps by coincidence), so distros should **not** try to link their Racket packages against `libkernel.a`, `scheme.h`, or any other such files from their Chez Scheme package.

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](https://github.com/cisco/ChezScheme/commit/822d815965da538faade8a5508c54b4bd8497d1a)).

---

_[View the full topic](https://racket.discourse.group/t/post-chez-10-distro-release-considerations/2739)._