Saw-mon & Natalie
Saw-mon & Natalie
> do you need unchecked here? > > https://github.com/wighawag/clones-with-immutable-args/blob/732be6078792f02caca0df341a75f1988008921f/src/ClonesWithImmutableArgs.sol#L25 @z0r0z , This unchecked block was carried over from the current implementation. The potential overflows that might be problematic would be:...
as @MarshallOfSound mentioned to unpack the asar archive you would also need a folder `app.asar.unpacked` in the same directory as your `app.asar` file. Read more here: [Adding Unpacked Files in...
I think an additional GitHub nightly release would be nice. That might make it really easy for example with `hardhat-vyper` plugin to pull the nightly without changing any of the...
I've created a GitHub workflow for the pre-release. Probably will make a PR for it tonight.
We could also use a tag like `x.y.z-pre-release` where `x.y.z` is the next semver version (adding 1 to the patch version number). Or following [PEP 440](https://peps.python.org/pep-0440.html), we could use `X.YpreZ`...
The workflow in PR #2920 can aslo be customized futher to specifiy a custom `tag_name`. Based on my findings from the different version comparisons, we have: - ✔ `hardhat-vyper` plugin...
Added a new commit to #2920 to unify the `pre-release` tag format. Now the `x.y.z-pre-release` format should work across the board. Already tested the `Vyper` setup and `hardhat-vyper` plugin and...
@charles-cooper , great point. I'll have to check that.
> interesting -- so the idea is to create a new pre-release release on every commit to master (as opposed to updating in place?) The decision to make a `pre-release`...
I can work on a PR for this.