combine bevy_ecs and bevy_hecs crates. rename XComponents to XBundle #863
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This combines the
bevy_ecs
andbevy_hecs
crates for a nicer project structure. For clarity, I have also renamed all "component bundles" to use theXBundle
convention instead ofXComponents
. Ex:PbrComponents
is nowPbrBundle
.This of course makes (eventually) consuming hecs upstream directly harder, but we've diverged so much at this point that I'm pretty sure reconciling the two code bases is too hard to be worth it:
We also have a number of (potential) planned changes:
Merging the crates doesn't change bevy's relationship to hecs. We will continue to direct user contributions upstream (when it makes sense) and I will continue referring to bevy_ecs as a "fork of hecs with layers on top" (which will only change if we swap out the archetype + world implementations entirely). I really like the "cross pollination" that we've got going on right now :)
I discussed this topic at length with @Ralith (the hecs creator / lead developer) and they were very much ok with the direction taken in this pr. They are also willing to try letting us re-license bevy's hecs code as MIT (so we no longer have a mix of mit and apache code). They've started discussing this with google, so we'll see if that pans out. If google agrees, we can start the process of asking each hecs contributor if they agree to license their contributions as MIT.
While we wait for licensing stuff to pan out, I'm adopting an Apache 2.0/MIT dual licensing approach. All of our bevy_ecs code (and hecs modifications) are dual licensed under MIT and Apache 2.0. All original hecs code is currently licensed exclusively under Apache 2.0. If/when the hecs code becomes MIT, we can drop the Apache 2.0 license and label everything as MIT.