Just as a general thought, maybe we should, as a community, try and define rules for when breaking backward compatibility is okay so that in the long term, we don’t have to keep maintaining legacy decisions and adjust a little easily to newer requirements in the field.
I agree, and am thinking that would be a good topic for the next community meeting. Forbidding any breakage in backwards compatibility removes the opportunity for incremental improvement. The only way to make resolve limitations in an initial design is to make an entirely new design (e.g. Relax → Relax), which is a painful transition of a different kind.
On a unrelated note: The use case related to using the branches of relax
IfNodeto implement different optimized versions of a model is really interesting, I’ve never thought about it, so thanks for that.
Thank you! It’s something that I’d like to incorporate into optimization pipelines more generally. I have a PR (link) that would introduce a relax.transform.CheckForSpecialCase, which would generate static versions of a dynamic relax function, and provide the appropriate IfNode in order to delegate to those static versions. (Though, it’s been on the back-burner for a while, and I still need to resolve a few CI issues with it.)