Including PreProcess and PostProcess functions

[vncoelho]

No description provided.

[jsolman]

It might have been nice if these has been in a separate plugin interface so that not all RpcPlugins would have to include them.

[erikzhang]

Why add PreProcess() and PostProcess()?

[erikzhang]

@jsolman You need to test before approving.
@vncoelho You need to test before merging.

[vncoelho]

There were fixes to be included due to modification in NEO core, plugins were broken.

We should merge the fix in the master or start to create a Dev branch with all fix before next release, otherwise it is hard to test up-to-date features.

[vncoelho]

@erikzhang, the idea is that all masters (neo, neo-vm, neo-cli and neo-plugins) should always build, when we merge in any of these 4 projects we sometimes broke the building process of the neo-cli.

I see that it is a good flow, in particular, I do not like much branching and all that kind of procedure.
Non-critical things can go to master as you have always been doing.

For example, yesterday I needed to test RPC wallet.
For that we would need to fix this.
The minor error was to go without public... aueaheuahea

Another idea we could implement is to merge everything in a branch before release. But I still prefer direct in the master.
We have a project that builds neo-cli with some automatic scripts: https://github.com/NeoResearch/neo-tests/tree/master/docker-build-neo-cli
We are planning to let a dedicated server monitoring all commits from these 4 aforementioned repositories and publishes building errors for everyone.

[erikzhang]

@vncoelho They can always be built. But they are not built for neo master branch. They are built for the last stable release of neo.

[igormcoelho]

@PeterLinX I just remembered your talk on DevCon regarding branching strategy 😄 perhaps it's time to adopt a development branch on the projects.

[vncoelho]

I agree with you, @erikzhang, as well as with @igormcoelho and the branching (personally, I do not like much these branching, but it may be necessary).

I thought that we were the only ones that rarely use nugets, but, recently, some people came to us on Discord asking why masters were not compiling and asking information about how to make a release from master.
I think that more and more people/devs are interested in following up-to-date commits and build their own releases.

On the other hand, that draft of Unit Tests that is opened will also provide a minor help, because Travis can detect if the PR is suitable for that specific Nuget.
Even if the test is not very complete it will test these basic things.

[erikzhang]

Then, they need to change. We are using nuget.

[vncoelho]

For nugets, what will help us the most would be to ensure Travis UT in every plugin project. Because travis will use the nuget in the master and verify if the proposed PR is suitable for that Nuget version.

Then, the PR will just be able to be accepted if NuGet is also updated.