Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neo v3.7.0 plan #2905

Closed
roman-khimov opened this issue Sep 14, 2023 · 52 comments
Closed

Neo v3.7.0 plan #2905

roman-khimov opened this issue Sep 14, 2023 · 52 comments
Labels
Discussion Initial issue state - proposed but not yet accepted Plan Plan for the next version

Comments

@roman-khimov
Copy link
Contributor

roman-khimov commented Sep 14, 2023

Summary or problem description
3.6.0 is out for a week. And we don't have any roadmap for 3.7. Fail to plan is plan to fail, so there has to be some.

Do you have any solution you want to propose?
We have a lot of open issues and PRs. In general my approach to them is:

  • simple and short problems should not sit in the queue for years, they're either accepted or closed (SJF)
  • anything affecting already existing applications has a priority (especially, bugs)
  • protocol changes should have some impact, enabling (opening new possibilities for a wide variety of applications) technologies are prioritized
  • sitting on a bunch of changes for a long time doesn't help, release more often

The list

Issues from this repository were moved into milestone: https://github.com/neo-project/neo/milestone/2
Below other repositories are being tracked along with items that require additional discussion.

Potentially 3.8:

The date
Dec 15 seems to be a good one for the list, enough to solve most of the important problems and with some room for unexpected things. The list can be adjusted if there are any problems, but there has to be a nice release this year .

Discussion
@superboyiii, @steven1227, core developers, Neo developers, dApp developers, random guys from the internet --- feel free to drop/replace this issue or edit it in any way. I'm not pretending that this is the list everyone should follow. Propose alternatives, kick some things out and bring interesting stuff in. The main thing here is to get this thing going and have at least some rough roadmap and schedule.

@roman-khimov roman-khimov added the Discussion Initial issue state - proposed but not yet accepted label Sep 14, 2023
@superboyiii
Copy link
Member

@neo-project/core @neo-project/ngd-seattle @neo-project/developers We could make discussion about this checklist as early as possible, especially for notary related proposals.

@cschuchardt88
Copy link
Member

Add neo-project/neo-modules#823

@roman-khimov
Copy link
Contributor Author

It's there as neo-project/neo-modules#822 (one entry is enough I think). Likely we need neo-project/neo-modules#825 though.

This was referenced Sep 18, 2023
@vncoelho
Copy link
Member

@roman-khimov, I was checking the proposed mandatory PRs.
Maybe just merge all three notary on the list into one (create an issue that list all three of them) because they need to be applied together.

Maybe postpone neo-project/proposals#160 because of time.
I think that Notary will take some time and the others PRs you defined as mandatory are kind of important ( I believe they were a good pick).

@roman-khimov
Copy link
Contributor Author

because they need to be applied together.

The beauty of this separation is exactly that they can be merged separately, there is not a lot of interdependencies between them and we believe this approach simplifies reviewing considerably (you can concentrate on one specific aspect, things like #2661 are almost impossible to review).

Maybe postpone neo-project/proposals#160 because of time.

I'd really love to have it since it's an enabler, it opens a number of new possibilities for all of the tools we have. And it's not a huge change either, just a little extension of NEP-14. From the node side this just means a little adjustment to supported manifest structures. But we'll see how it goes.

@vncoelho
Copy link
Member

I understand, @roman-khimov, For #2895 I do not see a reason to add role if the functionality is not implemented. I think it can be merged to another issue related to Notary.

Let's see how the extension goes in practice. We also need to study it careful to see possible impacts. It is also early as well, we reevaluate this later.

@Jim8y Jim8y added the Plan Plan for the next version label Oct 19, 2023
@Jim8y Jim8y pinned this issue Oct 19, 2023
@cschuchardt88
Copy link
Member

cschuchardt88 commented Oct 19, 2023

Neo really needs to make the system stable. Before adding new features to the neo ecosystem. It very annoying to develop on neo where it takes a lifetime to get a bug fix. These releases come out to FAST!!! If neo took the time to develop and actually have a dedicated QA Test team. We wouldn't be rushing for new version releases as soon as a release comes out.

So i say

should all wait until 4.0

@roman-khimov
Copy link
Contributor Author

I've removed the ones included in 3.6.2, some other updates will be proposed later. I'd use GH milestones and leave this issue for general discussion (which will be easier to do after #2944, now we still have references to other repositories).

@AnnaShaleva
Copy link
Member

@roman-khimov, should we include #2944 into 3.7.0?

@roman-khimov
Copy link
Contributor Author

It got some traction already, so likely yes. My initial thought was to limit it to vm/node part of the deal, but maybe we could arrange a complete solution (well, it's just modules besides that two) in 3.7.0 time frame. Not release critical to me, though. As usual, I'm a bit more concerned about protocol changes or fixes we deliver.

@roman-khimov
Copy link
Contributor Author

So, I've created https://github.com/neo-project/neo/milestone/2, #2974 and moved some things there. I still think we should have a release this year and with the current set of issues there are some chances for it (+/- some items). 3.7 will require a resync and I don't believe we can handle #1526 quickly, so it's moved to 3.8.

@lock9
Copy link
Contributor

lock9 commented Nov 17, 2023

@roman-khimov, should we include #2944 into 3.7.0?

Maybe we could add #2976 instead of #2944?

@roman-khimov
Copy link
Contributor Author

There are three things to merge (vm/node/modules). Go one by one. It doesn't really matter how many will be included into 3.7.0, from the user perspective it doesn't change the resulting product at all (at least until we make modules built-in, but that's not a quick thing even if we'd like to).

@shargon
Copy link
Member

shargon commented Nov 17, 2023

#2944 and #2942

@Jim8y
Copy link
Contributor

Jim8y commented Nov 17, 2023

There are three things to merge (vm/node/modules). Go one by one. It doesn't really matter how many will be included into 3.7.0, from the user perspective it doesn't change the resulting product at all (at least until we make modules built-in, but that's not a quick thing even if we'd like to).

I am seriously suggest adding compiler as well, debugging the compiler is also painful and need references to the neo and neo-vm.

@shargon
Copy link
Member

shargon commented Nov 17, 2023

There are three things to merge (vm/node/modules). Go one by one. It doesn't really matter how many will be included into 3.7.0, from the user perspective it doesn't change the resulting product at all (at least until we make modules built-in, but that's not a quick thing even if we'd like to).

I am seriously suggest adding compiler as well, debugging the compiler is also painful and need references to the neo and neo-vm.

If we override some methods we can make it easier

@AnnaShaleva
Copy link
Member

AnnaShaleva commented Nov 29, 2023

@roman-khimov, we should include neo-project/neo-modules#850. Not relevant, it will be a part of 3.6.3.

And I'd suggest to consider adding neo-project/neo-modules#852 (or at least discussing it). It's a minor issue, but it's still an issue.

@gsmachado
Copy link
Contributor

Hey @shargon @Jim8y @roman-khimov
What's the timeline for v3.7.0? (if any)

@roman-khimov
Copy link
Contributor Author

I'd love for it to happen end of March, but it'll released when it's done and realistically it's more like April to me. IIUC devpack already receives a lot of improvements independent of core changes and we need to solve a number of problems in core before release.

@vncoelho
Copy link
Member

vncoelho commented Feb 26, 2024

Can you update the checklist @roman-khimov ?

Maybe it would be better to release a version without notary and then release 3.8.0 quicker with this feature.

@Jim8y
Copy link
Contributor

Jim8y commented Feb 27, 2024

I have no special idea on if we should do something. But I hope this release is the last release that we need user to resync whole chain. (but not likely)

@mialbu mialbu mentioned this issue Feb 27, 2024
11 tasks
@roman-khimov
Copy link
Contributor Author

now we have upgradeable native contracts

Yeah, but we want C# node to be able to process NeoFS chains (of which there are two). For that to happen notary contract needs to be present since the genesis.

@gsmachado
Copy link
Contributor

I have no special idea on if we should do something. But I hope this release is the last release that we need user to resync whole chain. (but not likely)

God bless you, and all Neo users, to endure one more resync. ⚰️

I'll cry with happiness the day we roll out features without a full re-sync. 😭 🎉

Keep up the great work to make it happen. 🚀

@roman-khimov
Copy link
Contributor Author

I think we should not wait for a plugin to release a version

While idealistically that's the case, reality is --- users won't care much. This plugin (along with RPC server) is used by everyone and their dog, it's kinda a part of a standard installation (if it'd be something like StatesDumper that'd be a different story). So if you say "3.8 core doesn't require resync, but this plugin does" for users it still means "ugh, 3.8 requires a resync again".

@shargon
Copy link
Member

shargon commented Feb 27, 2024

now we have upgradeable native contracts

Yeah, but we want C# node to be able to process NeoFS chains (of which there are two). For that to happen notary contract needs to be present since the genesis.

Why from genesis?

@roman-khimov
Copy link
Contributor Author

Transactions will fail otherwise.

@shargon
Copy link
Member

shargon commented Feb 27, 2024

Transactions will fail otherwise.

But transactions will be executed with the contract already deployed, I'm missing something?

@AnnaShaleva
Copy link
Member

AnnaShaleva commented Apr 11, 2024

@roman-khimov, we should include neo-project/neo-modules#897 into release plan.

@AnnaShaleva
Copy link
Member

@roman-khimov, we should include #3194 into the plan as far.

@mialbu
Copy link

mialbu commented May 2, 2024

Hey guys, what's the state of this? Is there an ETA for Neo 3.7.0? Just that we can plan a bit.

@roman-khimov @AnnaShaleva @shargon @Jim8y

@roman-khimov
Copy link
Contributor Author

Seems like it'll happen when it's done. We've got an urgent request in #3205, it needs to be addressed (see nspcc-dev/neo-go#3425 also). Then there is a blocker in neo-project/neo-modules#897. Everything else seems to be optional even though we strongly suggest #2896 and #2897 (both have associated PRs and delaying them complicates future network maintenance).

@cschuchardt88
Copy link
Member

@roman-khimov
neo-project/neo-modules#897 with PR neo-project/neo-modules#898 should be ready to go. Been waiting for testing and review to happen. Seems last two weeks no one around. Everyone on vacation?

@AnnaShaleva
Copy link
Member

@roman-khimov, we need to include #2805 into the plan, otherwise users won't be able to properly calculate network fee for #3209 with C# node. It works OK with Go node, so WIP on this issue for C#.

@roman-khimov
Copy link
Contributor Author

I think we can handle #3209 without #2805 here. #2805 is much better, but it's invasive. Too risky for 3.7 to me, I'd try minimizing changes. Now that K-scripts are easy enough to parse we can have old-fashioned fee calculation scheme for them.

@AnnaShaleva
Copy link
Member

@roman-khimov, we need to include #3211, it's needed for proper work of #3209.

@AnnaShaleva
Copy link
Member

@roman-khimov, we also need to include #3200 into 3.7. There's already a PR that closes this issue, and it's LGTM.

@cschuchardt88
Copy link
Member

@dusmart
Copy link

dusmart commented May 10, 2024

neo-project/neo-modules#811 added twice, pls delete one;
seems that this list is not the final one, pls update it with all changes merged into master

@superboyiii
Copy link
Member

The master branch has been frozen and is ready to release v3.7.0,please don't merge any PR except change logs. @shargon @cschuchardt88 @Jim8y @roman-khimov @AnnaShaleva

@roman-khimov
Copy link
Contributor Author

Updated the list above and https://github.com/neo-project/neo/milestone/2 (at least in things that affect deliverables). 3.7 is out.

@roman-khimov roman-khimov unpinned this issue May 10, 2024
@dusmart
Copy link

dusmart commented May 10, 2024

congratulations for 3.7.0 coming out, hopefully the last one that needs re-sync

@roman-khimov
Copy link
Contributor Author

hopefully the last one that needs re-sync

This goal was certainly not reached this time.

@gsmachado
Copy link
Contributor

gsmachado commented May 10, 2024

This goal was certainly not reached this time.

wait, does it mean that to go from 3.7.0 to 3.7.1 would potentially need re-sync? 😭

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted Plan Plan for the next version
Projects
None yet
Development

No branches or pull requests