Open chillsauce opened 2 years ago
3.1 is the preferred option, waiting on costs and timelines. should have better sense in 1-2 weeks
Transaction lifecycle features may be ready to start testing in late May, or perhaps sooner
ENF will be sharing the acceptance criteria broadly for the transaction lifecycle features in the next week
Question from @matthewdarwin in Telegram:
I just want to make sure I understand what is in mandel 3.1. From what I heard, it has the following things:
Anything else planned so far?
The following EOSIO 2.1 items added into Mandel 3.1 (alongside what is already built in Mandel 3.0):
We're waiting for confirmation from Fractally team that they will commit to the 3.1 work
Dan's team confirmed they will be releasing 3.05 by early next week, which will include the following:
release.
ENF Engineers are all onboard by April 11
3.0.5 has been merged and is ready to be tested on Jungle https://github.com/eosnetworkfoundation/mandel/pull/38
There's no release yet, if you want to test you'll need to build your own binary. ENF will release when new devs start in 3 weeks. EOS Sweden is publishing their binaries. @cc32d9 will ask them to post this when it's ready.
Kevin will tag it as a release candidate 3.0.5 RC1 Fractally team will provide release notes for their changes. Kevin will provide release notes for OCI changes.
From the Fractally team: "We have not tagged this work/commit because there are obviously OCI and numerous community contributions still to be included for 3.1. In lieu of a specific tag, this PR shows the merge where we included the dfuse changes. Let me know if you need any further details."
3.0.5.RC1 is now tagged with release notes
Bucky will be joining on April 18, Matt and Areg (new ENF devs) joining on April 11th
Transaction lifecycle features tracking for early June to be ready for testing on Jungle
Request for another feature to backport: https://github.com/eosnetworkfoundation/mandel/issues/85
There are a number of additional features that would be good candidates to backport. Stan and Kevin will work on compiling a list.
Stan has already started a list: https://github.com/cc32d9/code_reviews
From @matthewdarwin :
Hello all,
As part of mandel 3.1 plans, it has been previously discussed that the "blocks.log splitting feature" is a necessary requirement for the release to be acceptable to the community. Recently, a question arose, as to what is the actual requirements necessary for 3.1 related to this feature.
It is my (and a few other people's view) that the desirable list of features for mandel 3.1 is as follows:
1) keep all the blogs.log, in a single file, as per nodeos 2.0 (no change). Starts from beginning or based on a snapshot.
2) keep some recent blocks, in one file (or optionally more files at the discretion of the developers), and remove old blocks when the configured number of blocks passes
3) don't store any blocks at all (this is a new feature, not in 2.1)
If you have opinions one way or another, please add thoughts to the github issues: https://github.com/eosnetworkfoundation/mandel/issues/100 https://github.com/eosnetworkfoundation/mandel/issues/92
Above also applies to "ship" (state history)
By late May/early June all 3.1 features should be ready for testing on Jungle
Patch released to enhance subjective billing: 2.0.14 Release notes draft is in progress and available: https://github.com/eosnetworkfoundation/mandel/releases/tag/v2.0.14
Targeting June 7 for go/no-go for Mandel 3.1 RC1 going into Jungle4
June 7 was a no-go. Next go/no-go will be on June 14. High likelihood it will be a go, there were only minor items left to address.
Features to consider activating:
Need to determine what limits to test on configurable WASM limits
The following EOSIO 2.1 items added into Mandel 3.1 (alongside what is already built in Mandel 3.0):
- Provide options for nodeos to automatically split the blocks log and state history logs (every X blocks).
- An eosio_blocklog utility that can read and split the logs.
- ~Merge the work of the dfuse team (deep-mind logger) that was included in the 2.1 release.~
- Remove deprecated features and modules listed at EOSIO Deprecations EOSIO/eos#7597
Hi, just a question about 2.1 Key Value tables. We have an enterprise customer using this feature. Last I checked, there was going to be a path in Mandel where this would be supported. Please could you confirm if this is still the case? https://eos.io/news/eosio-2-1/#key-value Thanks (Rewired.one) @chillsauce
planning for 3.1.0-rc2
would release mandel-cdt rc1 at around the same time
mandel-contracts rc1 would come later
Aiming to release RC2 with EVM and SHIP fixes next Tuesday, we will also require an RC3 to follow TBD date.
EOS Support has shared responses to the survey requesting feedback on fill-pg: 2979424562146452305fill-pg-feedback_update_20july22.pdf
Mandel 3.1 RC3 release is imminent - will likely become final assuming no issues found on Jungle after a week of testing
ENF are reviewing a few minor issues that have been reported for Mandel 3.1 RC3 and are meeting today to discuss the plan to address them and timelines. It is likely they are minor enough to go straight into the final release.
DUNE RC3 has been released to support CDT RC3 and Leap 3.1.0 Stable https://github.com/AntelopeIO/DUNE/releases/tag/v1.0.0-rc3
We are actively addressing the msig issue mentioned in the last two calls within this issue. We do not have a definitive timeline for eos-system-contracts v3.2.0 but this will be part of it https://github.com/AntelopeIO/reference-contracts/issues/7. Please note this issue is for reference contracts but the change will be in both places.
On the way:
As an EOS node operator, I need to know what version of EOSIO I should be testing on testnets so that I can be prepared for the eventual upgrade on mainnet.
Useful consensus features to consider activating by fall:
configurable WASM limits (careful - incorrect config could brick the chain. test all configurations on testnets)
get code hash
return value from action
[ ] Need to align on what consensus features we will activate