Let the nightlies call themselves 'nightly'. #64
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ekpyron
commented
Oct 15, 2020
ekpyron
force-pushed
the
developToNightly
branch
from
c264810
to
52aa3da
Compare
|
So on top of that, the main question is, whether we ignore that the nightlies so far, call themselves develop builds... |
chriseth
approved these changes
Oct 15, 2020
|
You are right, let's not change the old nightlies. |
|
Someone should verify tomorrow that this actually worked... (i.e. fetch the nightly and check that |
|
I'll verify that. |
|
I checked with So it's fixed. Out of curiosity I checked all the other soljson builds in the repo and unfortunately this is far from the only irregularity. Releases:
Nightlies:
Below is the full list of file names and versions they report. It was meant o be a markdown table but github wraps it in an unreadable way so I'm posting it as verbatim text instead - lines are long so remember to scroll right. Release buildsNightly builds |
|
I think that's mostly fine. You mean 0.3.6, 0.4.0 and 0.4.2, right? I don't see anything wrong with 0.4.1. The symlink for 0.5.17 we should add, though - that was probably an oversight on the backport bugfix release back then. The date differences in the nightlies were probably due to |
Right. Fixed.
Right. I can add it but I'll do it next week when I'm back because it doesn't seem very urgent (at least no one complained so far).
I guess the problem might be that if you start relying on getting it from the commit, you tie the build process to git and you can no longer just build from a source tarball. Or, in our case, you'd always have to either built from a git repo or have the file with commit hash on disk. Maybe some marker (e.g.
Yeah, I think it should be fine to keep them. The number irregularities shows that it's better not to rely on the reported version strictly adhering to any specific format. Given that we cannot correct them after the fact, it's still pretty good that in all cases they have the right version number and commit hash and that relases are clearly distinguishable from nightly and development builds. |
|
Source tarballs only exist for releases anyways, for which you don't need the date, don't they :-)? But we don't need to fix any of this right now anyways - we can just consider it when removing the weird prerelease.txt and commit_hash.txt logic anyways with ethereum/solidity#9720 |
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Otherwise they'll call themselves
developbuilds.