# Nushell core team meeting 2024-05-01
## Attendees
- Jack
- Ian
- Darren
- Antoine
- Andy
- Devyn
- Michael
- Andrés
- Wind

## Agenda
- [x] Release update. Do we need a patch release?
- [x] `$.major`, `$.minor` and `$.patch` in `version`? => better to use a plugin such as [`nu_plugin_semver`](https://github.com/abusch/nu_plugin_semver)?
- [x] serializing closures in NUON? see [#design-discussion](https://discord.com/channels/601130461678272522/615329862395101194/1235152984342790184)
- [x] Raw string syntax [#9956](https://github.com/nushell/nushell/pull/9956)
- [x] Move plugins to separate repos?

## Discussed Topics

### Sem ver in `version`

- Limited use case, nushell can easily parse the full version string.
- May be slightly more convenient, e.g. for tools like `atuin`.

### Serializing closures in NUON?

Cell paths? Closures? Should we serialize them?

- What's the future of NUON? Should this be a portable format, or should it be something useful for Nushell primarily?
- We don't have a spec. We just use the nu parser. Should we standardize and create a parser specifically for it?
- Jakub: maybe people would want to implement NUON in another language
- Want Sophia's input. Seems like the original goal is that it's more concise and supports more data types
- Tables are a major plus, compared to JSON? (also comments, trailing commas, dates, filesizes, durations, binary data, etc.)
- Compared to JSON5? What do we offer over that
- If NUON is going to grow in the wild, we need a spec. Up to whoever wants to start that.

### Raw string syntax

- Ready to land, but
- What should the syntax look like? `r#` like Rust?
- Rust also even supports `r##"string"##`, with any number of balanced sigils. Even zero
- Do we like `#`? It's our comment symbol
- Maybe we should not allow double quotes? Usually double quotes means escapes are allowed
- Sounds like `#` > `@`, and `!` is not well liked
- Go with `r#''#` for now
- Maybe heredocs later?

### Move plugins to separate repos

- Would be nice eventually, but might not be worth it now:
- CI concerns (which PR broke the plugin)
- nightly build with `main`?
- workflow build of out-of-repo plugins with each nushell PR?
- PRs often break plugins due to API changes
- Packaging concerns
- right now we distribute them together with nushell
- nupm is not mature enough yet for distributing the core plugins but hopefully someday it is
- In the future maybe plugins in their own repo could work similarly to the way we handle Reedline in its own repo ?
- Again the main issue here for now and the reason we are not going to move plugins to their own repo is because we need a way for nushell developers to know immediately that their code is breaking the plugins so they can fix the plugin code or their code prior to their PR landing.

## Issues
> :bulb: the issues which [needs-core-team-attention](https://github.com/nushell/nushell/labels/needs-core-team-attention)

> :bulb: **Note**
> to list all the PRs currently [opened in `nushell/nushell`](https://github.com/nushell/nushell/pulls):
> ```nu
> gh pr list --json url,number,author,title
> | from json
> | each {|i|
> $"- [($i.number)]\(($i.url)\) ($i.title) \(@($i.author.login)\)"
> }
> | reverse
> | to text
> ```