You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Git dependencies prevent us from being able to publish to crates.io (if we want to) and are also inherently unstable. Most of our git dependencies are for pull requests that haven't been merged yet (i.e. flume, cpal) or crates that haven't been updated on crates.io yet (catpuccin-egui).
The only exception to this is wezterm-term, which we use to handle most of the terminal functionality. We aren't really supposed to be using wezterm-term anyway, as it's a crate tailor made for wezterm and has no stability guarantees.
The text was updated successfully, but these errors were encountered:
We should probably wait a little for the flume and cpal pull requests unless there's some rush. I think we may need to make a subtree for catppuccin-egui though because they update more slowly than all of our other dependencies that depend on egui and the crate itself is very small anyways.
How is the current version of Luminol going to be determined from inside of Luminol if we publish to crates.io? The git-version macro isn't going to work properly if some of the crates are at a different git version than the other ones, so would we have to make a new update for every crate every time any crate is updated?
Yeah, there's definitely no rush! I'm actually working on a theme editor so we can replace catppuccin-egui (luminol-preferences branch)
The version should probably be defined by the luminol crate? git-version is there more to pin down when a build was made (useful for checking if your browser is caching wasm builds)
Git dependencies prevent us from being able to publish to crates.io (if we want to) and are also inherently unstable. Most of our git dependencies are for pull requests that haven't been merged yet (i.e. flume, cpal) or crates that haven't been updated on crates.io yet (catpuccin-egui).
The only exception to this is wezterm-term, which we use to handle most of the terminal functionality. We aren't really supposed to be using wezterm-term anyway, as it's a crate tailor made for wezterm and has no stability guarantees.
The text was updated successfully, but these errors were encountered: