# Tauri Devs Bi-Weekly Meeting Notes

## May 05, 2023

### Agenda

- [Tauri v1.3 release](https://tauri.app/blog/2023/05/03/tauri-1-3): NSIS support & fix for Remote URL accessing IPC
- @Yuwei: Domain lead for Development Domain based on [Governance model](https://hackmd.io/@Beanow/BJC5NXidj/%2FhG-Vp9XKRNCcpQESHz_Liw)
- There will be an experiment on Development Team. Choosing a team lead for project management around a month or two.
- It'll focus on release first. Prioritizing issues based on release requirements. The release to focus will be either 1.4 or 2.0. We won't finalize periodic release until the experiment ends.
- The goal is to find out the issue priority we need to focus. In the meantime traige and fix bugs with limited maintainers.
- We should also make the [project board](https://github.com/orgs/tauri-apps/projects/11) maintainable in the future and document the responsibility for team lead and the team.
- We want to deprecate core group this time. Further permission restrictions are coming across Discord and Github.
- @amrbashir: I honestly think we should have a product/project manager that has the sole purpose of sorting issues for releases and assigning them to the appropriate developer. we are also in need of a macos developer to help triage and fix bugs related to just macOS as I see there is a lot of macOS issues unattended and maybe a project manager could help assign these based on importance to the appropriate developer engineer.
- Domain lead needs to overcome members' difficulty.
- @Beanow: much overlap with Domain Leads concept, except that there's 1.
(Current draft discourages this and promotes 2-or-3.)
Can use a lot of this work https://hackmd.io/@Beanow/BJC5NXidj/%2FBpouwSCgSRaS4rBdX5hkMQ
- @Beanow: Keeping that in mind, probably avoid "Team Lead" as Teams would be a different concept there.
- Pushing version 2.0
- @amrbashir is 1.3 final v1 release? (@Yuwei: no if there's any CVE fix needs to backport)
There is multiple features and refactors that need to land in v2 ut we are currently kinda restricted and can't yet merge them into `next` branch as it will introduce huge conflicts with `dev` branch like this [PR](https://github.com/tauri-apps/tauri/pull/6692) that refactors `tauri-runtime` and `tauri-runtime-wry`. There is probably

- Is there a solutioin? @amrbashir: Yes, I think there is but it is not all rainbows and sunshine, however it should be good enough:

1. create `v1` branch
2. merge `next` into `dev`
3. new features, bug fixes or refactors should target the newly merged `dev` branch, just go wild with the changes, no need to wait for audit, review and merge in speed if possible.
4. backport important bug fixes and features (but no refactors, keep it minimal) to v1 and publish new minor releases if needed (still needs to be audited) which should be easier to do than maintaing two branches and keep merging them together
5. Define v2 features and scope and all engineering effort should work towards finishing them. Bellow are some proposing features added to v2 roadmap project on GitHub:
1. IPC data transfer improvements (through `fetch` and custom protocol?)
2. Move endpoints logic from core `tauri` crate to plugins (Lucas is working hard on this one, thank you)
3. Focus on improving the tauri codebase, currently we have some places that have comlex logic or scattered through differnet crates and it is hard to contribute to these code sections. See [this short conversation](https://discord.com/channels/616186924390023171/986184094050316358/1100424522382987375) where even I got confused and forgot where things are.
4. Improve and simplify Javascript APIs especially `fs` and `http`, see this [issue](https://github.com/tauri-apps/tauri/issues/2233) and related [PR](https://github.com/tauri-apps/tauri/pull/5136). This kinda conflicts with [capability-based security APIs](https://github.com/tauri-apps/tauri/issues/6107) so I am fine with just closing this PR but no one is currently working on capability-based security APIs and v2 mobile APIs ar expected to not be complete. Anyways, I think there is much value in this PR for desktop apps so maybe merge it for v2 and delay capability-based security APIs to v3 or move it to another unofficial plugin maybe? so it doesn't conflict with the new plugins? or maybe under a differnet name as `fs-extra` and `http-extra` or toggle the APIs using a feature flag?
5. Deep linking, I have a [PR](https://github.com/tauri-apps/tauri/pull/5554) in `tauri` but it is missing macOS implemenation, so I need someone to take it to the finish line along with this [PR](https://github.com/tauri-apps/tao/pull/422) in `tao`. Android and iOS should be delayed to 2.* minor release or maybe v3 giving that v2 mobile will probably missing a lot and basically we are just aiming for bare-minimum mobile support?
6. File associations (`Open this file with your tauri app`), see this [PR](https://github.com/tauri-apps/tauri/pull/4320)
7. Drag files out of a tauri-app into the file system, see this [issue](https://github.com/tauri-apps/tauri/issues/2593)
8. Go through the issues list and add the ones that qualify to land in v2 to the backlog so we can all work towards fixing/implementing this issues.

## Action Items

- Pushing IPC improvement along with or after V2.