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
Currently LFC is bound to a specific git revision of the crate, not a semantic version number. Using semver would allow us to publish bugfixes to the runtime without needing to upgrade LFC. But we also would need to maintain compatibility with the code generator, and also commit to the stability of the ReactionCtx and related user-facing APIs. I don't think the crate is stable enough right now to allow this.
If we start doing that, then we need a defined release cycle, possible using beta versions for all major versions that are not directly used by a released LFC version. Otherwise we will either clutter Crates.io with deprecated, unsupported releases.
The text was updated successfully, but these errors were encountered:
For what it's worth, I don't think reactor-ts is all that stable either. If there are many releases because there is a lot of development, then I think that is considered a good thing, not "clutter."
Currently LFC is bound to a specific git revision of the crate, not a semantic version number. Using semver would allow us to publish bugfixes to the runtime without needing to upgrade LFC. But we also would need to maintain compatibility with the code generator, and also commit to the stability of the ReactionCtx and related user-facing APIs. I don't think the crate is stable enough right now to allow this.
If we start doing that, then we need a defined release cycle, possible using beta versions for all major versions that are not directly used by a released LFC version. Otherwise we will either clutter Crates.io with deprecated, unsupported releases.
The text was updated successfully, but these errors were encountered: