Closed lpil closed 1 day ago
This would be a good addition to gleam fix
. It would be ideal if it could look at dependencies as well.
Questions:
I would say that I would only trust the minimal version number if I have a CI with this version passing and the CI with version-1 is failing. Maybe we can somehow work with this metadata?
Just features, we won't attempt to infer for bugs, and we won't depend on any CI systems or such for this information as there's too many factors for us to do it reliably, and it won't tell us the bounds.
@sobolevn are you planning to work on this? Otherwise I'll be giving it a shot today
@giacomocavalieri, please, go ahead :) I don't know the project's history well enough to do this.
So after reading through the changelogs I've written down all the features I think should be taken into account, I'll go with this in the coming PR, please let me know if anything shouldn't be included or if you notice something is missing!
@internal
annotation#(#(a, b), c).0.1
@
<>
used in constant stringlittle
, big
, signed
, unsigned
and sized floats in bit array
patterns and expressions on the js targetutf8
in bit array patterns on the js target:utf8
annotation for literal strings in bit array segments
Currently you can specify the minimum required Gleam version, but there's nothing to ensure that you have got it correct.
When analysing the code keep track of what features are used and use that to determine what the minimum Gleam version would be, and then complain if the version in
gleam.toml
is too permissive.We don't need to worry about v0.* versions.
We could automatically add it to the package config before publishing if none is set.