Now We're preparing the checklist of neo3-preview4 for task collection. We've already focused on these issues and PRs but we're also glad to collect other requirements. This checklist will be frozen on Dec 7th, then we'll work on these.
This release should be on 12/15 2020 (Can be moved forward if completed ahead). Then Preview4 testnet will be launched. And two weeks later, we will release neo-cli v3.0.0 and launch neo3 testnet. Formal testnet will nearly the same as Preview4 testnet, but chain data and seed nodes will be reset. Now we're focusing on these issues and PRs.
Since more PRs and Issues are coming to Checklist, we delay the release time for three weeks(12/15 2020)
Mandatory issues
OnPersist and PostPersist have the same application log hash https://github.com/neo-project/neo-modules/issues/354Mandatory PRs
magic field in getversion https://github.com/neo-project/neo-modules/pull/363exception field in invokeresult https://github.com/neo-project/neo-modules/pull/364Can we include https://github.com/neo-project/neo-modules/pull/335 plus a fix for https://github.com/neo-project/neo-modules/issues/343 in preview 4? Once 335 PR is in, I can do the work to fix 343 very quickly.
Looks good @superboyiii.
I agree with those two PRs, @devhawk, if you need any support let me know.
Who will proceed with "Allow oracle to access NeoFS", @roman-khimov @neo-project/ngd-shanghai? The template for the asynchronous has been merged. Will it come after we merge https://github.com/neo-project/neo-modules/pull/326 or you are already preparing it?
Who will proceed with "Allow oracle to access NeoFS", @roman-khimov @neo-project/ngd-shanghai? The template for the asynchronous has been merged. Will it come after we merge neo-project/neo-modules#326 or you are already preparing it?
We'll add this feature after https://github.com/neo-project/neo-modules/pull/326 merged.
I agree with those two PRs, @devhawk, if you need any support let me know.
FYI @vncoelho I had linked to the wrong PRs - the ones I was mentioning are in modules repo
Then I need to double check...aehuahuea The async RPC looks good in my opinion but not necessarily a feature that we need right now. But if you have in mind a good way to distribute its loads it would be good if it can come asap.
Then I need to double check...aehuahuea The async RPC looks good in my opinion but not necessarily a feature that we need right now. But if you have in mind a good way to distribute its loads it would be good if it can come asap.
You might not need it, but neo express does.
If it is a requirement perhaps it should be included.
We should have a simple Oracles sample for preview 4 developers
Can we include https://github.com/neo-project/neo-devpack-dotnet/pull/362 in checklist for preview 4?
Can we include neo-project/neo-modules#335 plus a fix for neo-project/neo-modules#343 in preview 4? Once 335 PR is in, I can do the work to fix 343 very quickly.
Done.
Can we include neo-project/neo-devpack-dotnet#362 in checklist for preview 4?
Done.
FYI @superboyiii I added the fix for neo-project/neo-modules#343 to neo-project/neo-modules#335
IIUC preview4 is supposed to have broader support from various community projects, especially ones that are more developer- and user-oriented, like compilers, wallets, light nodes and alike. These tend to care more about external interfaces provided by the node rather than internal improvements, thus I'd like to raise priority for some of the issues related to these external node interfaces.
neo-project/neo-modules#354 --- this one is a MUST before preview4 to me
neo-project/neo-modules#351, neo-project/neo-modules#337 --- affecting frequently used APIs, better deal with them now than leave post-preview4
neo-project/neo-modules#358, neo-project/neo-modules#355, neo-project/neo#1977 --- these are very important for some RPC clients
neo-project/neo-modules#334 --- minor, but easy to fix and helps a lot
neo-project/neo-modules#352 --- minor, but easy to fix
IIUC preview4 is supposed to have broader support from various community projects, especially ones that are more developer- and user-oriented, like compilers, wallets, light nodes and alike. These tend to care more about external interfaces provided by the node rather than internal improvements, thus I'd like to raise priority for some of the issues related to these external node interfaces.
neo-project/neo-modules#354 --- this one is a MUST before preview4 to me
neo-project/neo-modules#351, neo-project/neo-modules#337 --- affecting frequently used APIs, better deal with them now than leave post-preview4
neo-project/neo-modules#358, neo-project/neo-modules#355, #1977 --- these are very important for some RPC clients
neo-project/neo-modules#334 --- minor, but easy to fix and helps a lot
neo-project/neo-modules#352 --- minor, but easy to fix
All these are added.
Add https://github.com/neo-project/neo/pull/1973, as it's imcompatible.
Add #1973, as it's imcompatible.
Done.
Any chance of including #1966 in preview 4?
Is preview 4 the last chance for breaking changes? i.e. will we be able to consider making more changes for #1866 after preview 4? (such as #1952 and https://github.com/neo-project/neo-devpack-dotnet/pull/371)
Any chance of including #1966 in preview 4?
Sorry, Harry. This PR is excellent but it has made huge changes, maybe we could merge it to neo-core after neo v3.0.0 released and review it step by step.
Is preview 4 the last chance for breaking changes? i.e. will we be able to consider making more changes for #1866 after preview 4? (such as #1952 and neo-project/neo-devpack-dotnet#371)
We could take it into neo-core between preivew4 and neo v3.0.0.
All these are added.
Hmm, I don't see neo-project/neo-modules#355 there, any particular reason for that?
Any chance of including #1966 in preview 4?
Sorry, Harry. This PR is excellent but it has made huge changes, maybe we could merge it to neo-core after neo v3.0.0 released and review it step by step.
Is preview 4 the last chance for breaking changes? i.e. will we be able to consider making more changes for #1866 after preview 4? (such as #1952 and neo-project/neo-devpack-dotnet#371)
We could take it into neo-core between preivew4 and neo v3.0.0.
Any chance of including #1966 in preview 4?
Sorry, Harry. This PR is excellent but it has made huge changes, maybe we could merge it to neo-core after neo v3.0.0 released and review it step by step.
Is preview 4 the last chance for breaking changes? i.e. will we be able to consider making more changes for #1866 after preview 4? (such as #1952 and neo-project/neo-devpack-dotnet#371)
We could take it into neo-core between preivew4 and neo v3.0.0.
1966 has changes related to #1866 (i.e. domain model unification) and #1865 (domain model decoupling). I'm much more concerned about getting changes related to unification in before shipping v3 than decoupling. Can we do a post preview 4 PR to move types like Block and Transaction to the Neo.Models namespace?
@shargon @erikzhang What's your opinion?
All these are added.
Hmm, I don't see neo-project/neo-modules#355 there, any particular reason for that?
A mis, add it back now.
https://github.com/neo-project/neo/pull/2041 is quite simple (makes BinarySerializer class public). Can we include this in preview 4?
2041 is quite simple (makes BinarySerializer class public). Can we include this in preview 4?
Sure.
@superboyiii I believe https://github.com/neo-project/neo-modules/issues/385 is a must fix for preview 4. Invoke script RPC method script parameter handling doesn't match between RpcClient and RpcServer
@superboyiii I believe neo-project/neo-modules#385 is a must fix for preview 4. Invoke script RPC method script parameter handling doesn't match between RpcClient and RpcServer
Fixed in https://github.com/neo-project/neo-modules/pull/386
Are we switching to net5.0 target framework across the whole neo project? If so, is this going to be in preview 4? If we make that switch in Neo.VM, that means all downstream projects have to switch as well. I tried pulling the neo.vm change into https://github.com/devhawk/neo-monorepo and none of the downstream projects compile anymore.
Are we switching to net5.0 target framework across the whole neo project?
I think that is not for preview 4
Are we switching to net5.0 target framework across the whole neo project?
I think that is not for preview 4
the net5.0 change has already been made in neo-vm project. So is the plan to create a preview 4 fork at the commit before the change was made?
I think this needs to be fixed for preview 4: https://github.com/neo-project/neo/issues/2072
I think we'd better review and merge this two incompatible PRs first. https://github.com/neo-project/neo/pull/2044/ https://github.com/neo-project/neo/pull/2056/
I think we'd better review and merge this two incompatible PRs first. #2044 #2056
https://github.com/neo-project/neo/pull/2044 need https://github.com/neo-project/neo-devpack-dotnet/pull/388 and https://github.com/neo-project/neo-devpack-dotnet/pull/391, I think we can review and merge it as soon as possible, then test it together.
https://github.com/neo-project/neo/issues/2085 looks like another issue that needs to be fixed for preview 4, but given the in-flight state of some of the NEP-17 related stuff, a fix for this might already be waiting to merge.
Hello,
There are a few items not checked on this list. Is the release date going to be postponed?
~I hate to add to this list, but #2151 needs to be fixed for preview 4.~
I can work around #2151 in neo express by calling setMinimumDeploymentFee, but I think this should be fixed for preview 4
is it delayed again? adverse situation for the investor
@kelimelogg There are always some delays on software projects, but you shouldn't worry, they are delaying it because they want to make it right. It is a healthy delay.

Please release Neo3 so I can sell.
what else is expected?
Most helpful comment
@kelimelogg There are always some delays on software projects, but you shouldn't worry, they are delaying it because they want to make it right. It is a healthy delay.