Heron is discontinued

[jcornaz]

Heron is being phased out

Today starts the end of life of heron. It now enters a « maintenance mode », meaning I’ll continue to accept pull-requests and merge them (provided they come with tests and the build pass). But I am not actively working on heron. As soon as bevy 0.9 is released, heron will be immediately discontinued. This means heron will never support bevy 0.9.

The alternatives

Instead of heron, I recommend bevy_rapier.

edit: by the way, bevy_rapier ergonomics have improved a lot since the creation of heron, and there is less need for heron than there used to be. I wouldn't have created heron if bevy_rapier's API had been in the state it currently is.

Why

I made multiple mistakes, that are too hard to recover from without starting again from scratch. Here they are:

Public dependency and tight coupling on rapier

As much as rapier is powerful, in heron I made the mistake of not hiding this dependency. This led to multiple pain points for me down the line, as well as confusion for the users, because it is never really clear if a behavior is caused by heron or rapier. And building this layer between the actual physics engine and the user, is actually not so pleasant for me, not to mention the painful breaking changes in rapier. But heron is a hobby project, so what's the point if it is not pleasant to develop? If I have to redo heron, I’d rather build the physics engine myself instead of wrapping an existing one. Or a least hide better the engine and have a level of abstraction to keep the coupling loose and make sure I could switch the physics backend later.

Public dependency and tight coupling on bevy

As much as I love to use bevy for my own projects. I realized that it is a not great experience to maintain a library that publicly depends on it. Because bevy warns in its readme that the engine is in its early development stage, that is used as a license to break the API all the time without trying to stabilize it. For example, struct fields are public, and the dependencies are not encapsulated, not to mention that all bevy crates are versioned together. And it is the plugin authors who get pressured to update to the latest version of bevy as fast as possible, because our plugins are basically obsolete until we upgrade.

I think bevy is an awesome engine. But I don't want any of my libraries to have a public dependency on it anymore. I made benimator an engine-agnostic library and for impacted I won't add support for the next versions of bevy. But for heron, I made the mistake to couple it too much with bevy. I don't see any way forward that would be easier than a full rewrite. Therefore, I am discontinuing the project.

[zicklag]

Thanks @jcornaz for all your great work! I understand the burden, and how this is a particularly tricky thing to keep up with, even if you did enjoy working on it.

For what it's worth, I think the official bevy_rapier crates have improved dramatically on their UX, and I don't mind using them at all anymore, so I think that the need that Heron filled isn't as deeply felt as it used to be.

Anyway, thanks again, and good luck with your future developments!

[jcornaz]

Thanks for the kind words, and for your valuable contributions to heron.

Indeed bevy_rapier's UX has improved dramatically, and I am happy to see all the good improvements it received.

[sebcrozet]

Hey @jcornaz! Thank you so much for all the work you put on heron.

I wouldn't have created heron if bevy_rapier's API had been in the state it currently is.

The funny thing is, bevy_rapier wouldn’t have the UX it has today if heron didn’t exist in the first place. heron has been a big source of inspiration for bevy_rapier and it helped me a lot understanding what the bevy community would expect in terms of UX. All the time you put in heron have been an extremely valuable contribution to the bevy ecosystem, and to bevy_rapier itself.

Good luck with your new projects!

[micsama]

good luck bro~