Plans for a v1.0.0 release?

[mortenfyhn]

Hi! I think this library looks wonderful, and I'm very interested in using it in my company. Do you have plans to release a stable v1.0.0? I'm guessing many "production" use-cases would require that. It would certainly make it easier for me to integrate au.

[chiphogg]

Thanks very much --- we're excited you're interested in Au!

I guess the answer is technically "no", in that we've never made an explicit plan for what would go into a 1.0.0 release. However, I can say a few more things which may be helpful.

The first is that the library has a lot of "stability pressure". It's been continuously used in production for 2 years, in a large codebase, at a company which is highly focused on building a product and getting it out the door (long-haul autonomous trucking). So, there is zero appetite for any significant breaking changes.

Second, the changes we do anticipate will be additive. Examples include:

• Consider separating "forcing" from explicit-Rep #122 (the first part, where we provide new APIs without changing the old ones)
• Provide runtime convertibility checks #110
• Indicate relative magnitudes in common unit labels #105
• Support constants #90
• Solve most [UNLABELED_UNIT] instances by generating magnitude labels #85
• Support matrices, vectors, and linear algebra #70
• Support non-arithmetic Rep #52
• Support abbreviated symbols #43

So, these shouldn't cause any issues when upgrading to new versions of the library.

Third, what are the breaking changes we can foresee at this point?

• Avoid names which differ only by T #86 --- should cause very few or zero breakages, since most end users wouldn't name the affected constructs in their code
• Rename Magnitude numerator/denominator traits #83 --- similarly, I don't think end users are using these directly much if at all
• Change Fahrenheit label from "F" to "degF" #60 --- not sure how many people rely on Fahrenheit being labeled F, and anyway they can preserve the old label by inheriting a new unit
• Tighten up integer division checks on Quantity #39 --- if this causes any failures, it's probably in lines of code that people will want to look at anyway!

The one possible "significant" breaking change I could imagine would be related to #122, where we might change the "explicit-Rep" semantics so that it respects the safety checks. If that does happen, then the first thing that would happen would be that we'd add new APIs with the "force" word, such as .force_as() and .force_in(): these APIs would be available for a while so people could adapt. And we'd need to make sure that the error message from using an explicit-Rep tells people exactly what to do instead, so that when clients do make the (explicit) upgrade, it'll be easy to fix everything.

I can make this easier by doing the "first part" of #122 sooner, so people can start using those APIs now (assuming they work out; if they don't, then the "forcing" explicit-Rep is here to stay anyway). I'm not sure when I'll get a chance to take a crack at it.

Finally, just for calibration purposes: how fast should we expect all these changes? Well, we're heavily focused on the trucking product for the foreseeable future (targeting a release sometime midway through 2024), so I would expect to see an average of 1 or 2 issues per month resolved on this library on average, depending on the (highly variable!) complexity of each issue.

[mortenfyhn]

Thank you very much for the highly detailed write-up! I imagine this info will be useful for many others also. It sounds like stability/reliability/testedness of the library is very good already.

I'll close this as resolved.