Needs to reach version 1

[John-Nagle]

Many graphics crates use glam. Not all use the same version. This results in having to pin old versions of crates to get them all on the same version of glam.

The graphics ecosystem needs a solid version 1. From there, enhancements can be added, but don't break the existing API. Thanks.

[bitshifter]

There is one largish change I have in mind for glam before calling it 1.0 but I need to find the time to experiment with it, write it up and discuss with the community. One that happens (or the idea is rejected by the community) then I think I could call it 1.0.

[John-Nagle]

It's hard to think of any change that would justify the massive efforts required in other crates for a breaking change.

[bitshifter]

In short I'm looking at moving away to defaulting some types to using SIMD registers and requiring 16 byte alignment and instead making separate explicit types for that. There are a bunch of reasons why. I'll talk about it more once I've had time to collect my thoughts and written about it, I doubt it will break much existing code.

[bitshifter]

I spent some time working on this idea of splitting types into explicit float and SIMD versions, much like Vec3 and Vec3A but for all of the other types that use SIMD, e.g. splitting Vec4 into Vec4 and Vec4A and so on. For anyone who is interested the changes are here main...experimental. I was attempting to modify a fork of bevy to use this branch which made it pretty clear that this would be quite a disruptive change, so I have backed away from this idea. It also introduces way more types to glam.

The reason I was considering it in the first place is there is a cost to many types being 16 byte aligned and it is not always clear that the benefits outweigh this cost. In microbenchmarks they do but microbenchmarks are not representative of real game code.

In any case, people seem largely happy with glam as it is and as you say many projects depend on it, so I think it's best to not make any large changes at this point. Now that I've finished with the aarch64 neon work I'll focus on getting to 1.0, which will mostly involve making sure any outstanding issues that would be breaking changes are done before then.

[John-Nagle]

Thanks. That's probably a good decision at this point. Churn in low-level crates forces churn in other crates.

[bitshifter]

I made the realisation that while all glam's dependencies are optional, when enabled they are all part of the public API except for libm and most of them are also not 1.0. Because they're public if any of them have a version bump that's a breaking change for glam which will require a version bump of glam to update the dependency. There's even a Rust API guideline that says a crate can only be stable if all it's public dependencies are stable https://rust-lang.github.io/api-guidelines/necessities.html#c-stable. That said, if I adhere to that I don't think glam will ever be 1.0. Ideally 1.0 would mean I don't intend to make significant API changes. That said if I did make some breaking API change in the future, it would be indistinguishable from a dependency version bump, which is unfortunate. Ultimately my feeling is it would be good to stamp glam as 1.0 when I consider the API to be stable, regardless of what dependencies are doing. As far as stability goes, I need to make a couple of breaking changes but they're very minor API changes. Prior to that there haven't been any breaking changes for a year now.

dependency	version	comment	link
approx	0.5	largely inactive but stable	brendanzab/approx#70
arbitrary	1.4	stable!	n/a
bytemuck	1.24	stable!	n/a
encase	0.12	actively developed	none
mint	0.5	largely inactive but stable	kvark/mint#31
rand	0.9	actively developed	rust-random/rand#693
rkyv	0.8	actively developed	none
serde_core	1.0	stable!	n/a
speedy	0.8	inactive but stable	none
zerocopy	0.8	actively developed	none