-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add VERSION file #6966
Add VERSION file #6966
Conversation
src/compiler/crystal/config.cr
Outdated
# Set explicitly: 0.0.0, ci, HEAD, whatever | ||
config_version = {{env("CRYSTAL_CONFIG_VERSION")}} | ||
return {config_version, nil} if config_version | ||
config_version = {{ `cat #{__DIR__}/../../../VERSION`.stringify.chomp }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing call to cat
, used again in the codebase (windows support coming, ekhem) made me open #6967
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if a macro is added, we can't use it until the next release. Until then an ifdef
/type
would be needed.
why not a constant in crystal source? |
It’s a nice asset to have the version in a plain file i think. Easier to change (eventually by a bot if you want ;-) ) |
I'd also like a way to specify the commit SHA explicitly, either in VERSION or an env var. Development builds shouldn't depend on using git on the build system. That's relevant for example when package managers provide edge builds. That could be added separately, though. IMHO it would also be better to move the git logic out of the compiler, and just provide a value by the build system like in #6748. It feels much cleaner to not have this hard coded into the compiler. And I would suggest to add a sanity check to make sure the version is a valid semver version compatible with |
src/compiler/crystal/config.cr
Outdated
{% else %} | ||
{{ `cat #{__DIR__}/../../../VERSION`.stringify.chomp }} | ||
{% end %} | ||
git_describe = {{ `(git describe --tags --long --always 2>/dev/null) || true`.stringify.chomp }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git rev-parse --short HEAD 2> /dev/null
returns the sha directly. No need to parse the describe string.
perhaps it would also be a good idea to add a CI check to fail the build if we're building a tag and VERSION isn't the same as the tag name. |
Well, at that point it's too late anyway... Need some kind of preliminary check |
@oprypin it's not too late to release another version bump at that point. If you're following the release checklist, it will "never happen", but I'd rather have more layers of safety than are required. |
If you run the specs locally before pushing the release, it's not even to late. |
src/compiler/crystal/config.cr
Outdated
tag = "#{tag}+#{commits}" unless commits == "0" # Reappend commits since release unless we hit it exactly | ||
|
||
{tag, sha} | ||
{config_version, sha} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this could be separated into two methods now. Unless we'd want to consider the option of specifying the sha in the VERSION
file as well, there is no longer any shared logic between "computing" version
and sha
.
@straight-shoota @RX14 I applied all the suggestions so far. |
What do you think about specifying the SHA as an environment variable? It should at least be optional (when not building in a git environment). I'd even prefer it as the only means and provide the value from the Makefile/build script. It would be cleaner not to call |
@straight-shoota ok. it will require some changes in the distribution scripts doing this (and I am a bit reluctant usually to do it) A |
|
@j8r It matches the method name |
That's fair. The point is the method/variable name don't tell what they are – what is a "Crystal config sha"? The method can be renamed to something from |
I wanted to avoid changing api as much as possible. We can call the method |
I don't mind the naming. |
fdc5fab
to
b20dc6b
Compare
src/compiler/crystal/config.cr
Outdated
@@ -5,15 +5,18 @@ module Crystal | |||
end | |||
|
|||
def self.version | |||
version_and_sha.first | |||
{% if flag?(:windows) %} | |||
{{ `type #{__DIR__}/../../../VERSION`.stringify.chomp }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indent this line?
Ditto below.
b20dc6b
to
adb9614
Compare
Compiler version is now fixed in the source git describe is used to show sha if available
Move git rev-parse to Makefile
adb9614
to
c449597
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great 👍
So as an alternative to #6964. This PR moves to a plain
VERSION
file that is embedded at compile time. If git information is available the sha is present as before, but is not part of version number.The version could have
0.26.2-dev
the only important thing is to be greater than latest. But since we know the next version is0.27.0
we can use0.27.0
(nb:0.27.0-dev
<0.27.0
)Closes #6964. Fixes #6715. Fixes #4642. Closes #4687.
Update:
Also a
CRYSTAL_CONFIG_BUILD_COMMIT
env var is used to specify the build commit. The Makefile grab this information from git if available.Closes #6748.