---
# System prepended metadata

title: Chris/Simon sync

---

# 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.