Neo: Should we make Preview5 out as the final Preview version?
As we planned before, Preview4 is the final version as Preview which is aimed to be a standard for community SDK development and the next version should be a formal one for formal test. Although formal testnet will have 2 or 3 version as iteration to make neo more stable, but current neo seems still has some PRs which are not compatible such as https://github.com/neo-project/neo-vm/pull/382 and .Net 5. Maybe Preview5 is better to make everthing compatible for formal version on testnet but we have to make sure it will not increase the development cycle between Preview4 and the formal version because of the Roadmap. What's your opinion? @neo-project/core @neo-project/ngd-seattle @neo-project/ngd-shanghai @erikzhang @roman-khimov
superboyiii
All 9 comments
In my opinion, we can't avoid the incompatibility PRs in short term. Even if Testnet is released, it may still have. Therefore, I suggest that the next version still be Testnet. We're too many preview-x version.
Tommo-L
on 17 Dec 2020
steven1227
on 17 Dec 2020
If we move to .NET 5, we will have no choice but to release new post-preview-4 binaries of all .NET based tools. We don't need to call that release "preview 5". Riffing off what @Tommo-L said, we could call the next "testnet-preview".
Once we release testnet, I think we should start treating all changes to the Neo 3 codebase the same way that changes to the Neo 2 codebase. That is, I think all changes that come in after the testnet is released must support being deployed into a running chain with decentralized nodes that will not all update at the same time - no cheating and resetting the testnet. That gives us a small window for breaking changes (like moving to .NET 5) before testnet release. But the more changes we take in, the harder it will be to hit the testnet release dates.
Maybe we should start a testnet release checklist now
devhawk
on 17 Dec 2020
I think we can call it whatever you guys want, preview, testnet, beta, alpha, or whatever, but please, could we use a branching strategy for this?
We were prepared to leave for the holidays, we made everything compatible with Preview 4, but I just saw a PR changing the NEF file :(
lock9
on 17 Dec 2020
they tagged the preview 4 versions of neo and neo-vm
devhawk
on 17 Dec 2020
It looks like there is still things to fix on Application Logs tag for neo-modules.
I agree with a new tag like "testnet-preview", sounds good @devhawk.
vncoelho
on 17 Dec 2020
It looks like there is still things to fix on Application Logs tag for neo-modules.
Which issue?
superboyiii
on 18 Dec 2020
I downgraded the version and was able to compile, @superboyiii . I was using sdk:3.1.400-focal and now 3.1.100-bionic.
vncoelho
on 18 Dec 2020
Close this by https://github.com/neo-project/neo/issues/2171
superboyiii
on 25 Dec 2020
Related issues
garrey332
路
3Comments
borovik96
路
4Comments
realloc
路
4Comments
igormcoelho
路
3Comments
vncoelho
路
3Comments
Most helpful comment
If we move to .NET 5, we will have no choice but to release new post-preview-4 binaries of all .NET based tools. We don't need to call that release "preview 5". Riffing off what @Tommo-L said, we could call the next "testnet-preview".
Once we release testnet, I think we should start treating all changes to the Neo 3 codebase the same way that changes to the Neo 2 codebase. That is, I think all changes that come in after the testnet is released must support being deployed into a running chain with decentralized nodes that will not all update at the same time - no cheating and resetting the testnet. That gives us a small window for breaking changes (like moving to .NET 5) before testnet release. But the more changes we take in, the harder it will be to hit the testnet release dates.
Maybe we should start a testnet release checklist now