# Chris/Simon sync ## ReleaseNotes ✅ * `GET /.../releases/<version>/releaseNotes` * `GET /.../branches/<branchRef>/releaseNotes` ## Project endpoint changes ✅ * A new field on a project called `latestVersion`. Is a nullable string. * A new `defaultBranch` field. Is a nullable string ## Releases endpoint changes ✅ Want to show the latest 3 unpublished drafts on the releases page. If the latest version is `1.0.0` and a draft `releases/drafts/1.2.3` is published we normalize to the nearest valid version, `1.0.0` in this case. When doing the draft version (`1.2.3`) is still higher than `1.0.1` and will show up as a suggestion in the UI. Even if we hide it, what would even happen when we go to actually release the real valid version of `1.2.3` and there is a previous draft branch existing. Options: 1. New field on release called `sourceBranch` which is a string 2. Release has `causalHashUnsquashed`. A branch has `causalHash` 3. The backend has a endpoint to get unpublished drafts * show the latest 3 drafts by updated at * filtered by causalHash matched with releases causalHashUnsquashed 4. You can't create invalid draft versions in ucm Open questions: * Should we delete drafts on publish? Probably not ### Decision Extend the `../branches` endpoint with a new parameter called `?unpublished` (`unpublished=true` as an alternative). ``` /users/hojberg/projects/html/branches namePrefix=releases/drafts&limit=3&unpublished ``` ## Readmes in perspective ✅ Currently getting the readme of a perspective is done with the namespace details API: ``` GET /users/hojberg/projects/html/branches/main/namespaces/by-name/public.base ``` 1. Render a readme based on a path in, * /branches/main/readme?withinNamespace=foo.bar.baz * Major downside here is Simon has to potentially refactor a lot of code 2. `/namespaces/by-name/:name` can accept no name 3. `/namespaces/by-name/.` means the root like it does in ucm. (for branch, release, and loose-code apis) https://api.unison-lang.org/codebases/unison/namespaces/by-name/public.base.latest ### Decision We're going with option 3. Yay! ## termNames ✅ Why are they absolute names? * I use the full names to deduce the namespace of the open definition to show the immediate namespace option (which allows users to switch perspective to that perspective) * The full names are useful for the user as the "other names" (which this powers), might be in a sibling perspective (which was the case in the below example). ### Decision termNames/typeNames should remain in the same format as it is on trunk right now. We're going to prepend the perspective manually onto the termNames/typeNames, not do anything with the rest of the pretty printing.