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

[alerque]

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]

@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]

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]

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.