Joshua Haberman

Quoting from my original report: >My project only works with certain versions of Bazel. I would like to warn users if they are building my project with an unsupported Bazel...

That works for enforcing certain versions, but it doesn't help for the case of falling back to different code for older versions. Is there a reason *not* to allow this...

I just read the doc [Bazel feature detection in Starlark](https://docs.google.com/document/d/1HJf3gMYIrzmTRqbD4nWXH2eJRHXjLrOU0mmIeZplUzY/edit#heading=h.5mcn15i0e1ch) where the idea of exposing `native.bazel_version` to rules and macros was considered and rejected again in March of 2023 (see...

# An argument for tail calls Based on my experience with https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html, I would strongly recommend offering guaranteed tail calls as one tool available to interpreter writers (I'm not arguing...

@ifreund that is great news, thanks for the info. :)

This sounds great; I haven't taken a look at the code yet, but from the description this sounds like just the right approach. > that's something which will have to...

> Similar changes as you've already made in ruby-upb.h to apply the UPB_API macro may also needed in ruby-upb.c. I think they should be made in the `upb` tree instead....

> but if there's some automatic process which is supposed to address that I can drop c93913c Yes, there is an automated process that will regenerate the files; for example...

Sorry for the delay. I think there is still an unresolved comment from me in the code. In the tests you have a comment saying that there is no API...

> force one or both projects to always build upb statically, and absorb all relevant symbols them into the respective builds (not a good idea from our POV) FWIW this...