Skip to content

It seems fluent_bundle is a "public dependency" of fluent. So a semver bump in fluent_bundle should require a semver bump in fluent. #385

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alerque opened this issue May 22, 2025 · 3 comments · Fixed by #386
Assignees

Comments

@alerque
Copy link
Collaborator

alerque commented May 22, 2025

It seems fluent_bundle is a "public dependency" of fluent. So a semver bump in fluent_bundle should require a semver bump in fluent.

The result of this is that projects depending on fluent and i18n-embed are getting errors about incompatible types (from different versions of fluent-syntax) when running cargo update.

Originally posted by @ids1024 in #383 (comment)

@alerque
Copy link
Collaborator Author

alerque commented May 22, 2025

@ids1024 You might have a point, that's kind of a weird export to start with and documented as not the way we expect FluentBundle to be used, but still it's there. And cargo semver-checks did not catch this! That may be a bug too...

Can you give me an example of why one would need to depend on fluent directly in addition to i18n-embed?

@ids1024
Copy link

ids1024 commented May 22, 2025

Or actually, looking at it the project depends on i18n-embed-fl, and doesn't directly depend on fluent.

But the issue is the same anyway. i18n-embed depends on both fluent and fluent-syntax. So the cargo tree ends up listing fluent-syntax 0.11.1, and 0.12.0. And there are compile errors from the types not matching.

For a minimal example of this, https://github.com/kellpossible/cargo-i18n/tree/master/i18n-embed/examples/library-fluent fails to build. (Or was, with a cargo update just before the yank).

@alerque
Copy link
Collaborator Author

alerque commented May 22, 2025

Yes, same core problem. Both the fluent crate here and the i18n-embeded crate are probably designed wrong. But yes the release did not play nice. I yanked it from crates.io and that should ease off the problem for the moment. We'll get a compatible release out soon.

Closing as a duplicate of #384.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants