Also need to test on machine with no dotnet installed on it.

@cschuchardt88 congrats on this PR! I've been waiting for this for such a LONG TIME. 👏

I will be testing on osx-arm64 and osx-x64 sometime this weekend. 👍

Hi @Liaojinghui,
I think it shouldn't be merged. There are too many binaries and too many files

@cschuchardt88 please latest os only in another pr.

strategy:
matrix:
os: [macos-11, macos-12, macos-13, ubuntu-20.04, ubuntu-22.04, windows-2019, windows-2022]

Hi @Liaojinghui, I think it shouldn't be merged. There are too many binaries and too many files

@lock9 You mean on release? @gsmachado how do you think?

If you want to merge it as is, ok, but I think we should try to improve it so it looks more like this in the future https://github.com/neo-project/neo-node/releases/tag/v3.6.2

It deals better with the hashes and platforms.

If you want to merge it as is, ok, but I think we should try to improve it so it looks more like this in the future https://github.com/neo-project/neo-node/releases/tag/v3.6.2

It deals better with the hashes and platforms.

@lock9 we can discuss about it. but in the meanwhile, please also check the updates in the workflows.

@lock9 we can discuss about it. but in the meanwhile, please also check the updates in the workflows.

I don't know why some URLs were changed but I assume that it's because we are going to use MyGet now? I really don't know. Do you know? 😅

I've tested the osx-arm64 build and it was working fine. I saw that there are other changes not related to the workflow, but they are related to the Neo 3.6.2 upgrade.

I think that this change is enough for now #358 (comment)

@lock9
These sha256 files would be used when deploying to brew apt-get repo or winget usage. Where else are we going to storage it for deployment?

If it's a requirement, ok. It's better to do separate PRs or at least explain it on the PR.
Note: I don't think we need win-arm64. People do not use it. I think it's fined to keep the hashes if they are used later and must be distributed like this.
Note 2: I don't think we need linux-arm64 either

Why have osx-arm64? My reasoning is that is a standalone app it doesn't require dotnet to be installed. Otherwise they can use portable if they have dotnet installed or the dotnet tool command.

Why have osx-arm64? My reasoning is that is a standalone app it doesn't require dotnet to be installed. Otherwise they can use portable if they have dotnet installed or the dotnet tool command.

It's because osx-arm64 is used by Apple M1 chips. Other manufacturers don't offer arm based cpus for computers (mostly used on mobile devices)

ill merge this one, further issues can be fixed in another pr.

@cschuchardt88 publish workflow error.

@Liaojinghui ${MYGET_TOKEN} is missing from variables. Have to add it to the secrets or server environment variables.

if its added, we may need to do ${{ secrets.MYGET_TOKEN }}

@Liaojinghui let me know when ${{ secrets.MYGET_TOKEN }} is added.

@cschuchardt88 @Liaojinghui guys, where's linux-musl-arm64? 😢

For example, alpine uses musl as its default C library. I think it's super useful besides the usual linux-arm64.

linux-arm64 and linux-musl-arm64 are the ones most used for, e.g., raspberry pi (and its clusters), schools, etc.

@gsmachado ya i think so too. but have people that think overwise. I'll add it back, because no cares this about this repo.

@gsmachado ya i think so too. but have people that think overwise. I'll add it back, because no cares this about this repo.

I agree 100% with your comment here: #358 (comment)
This table is just missing the osx-arm64, which was added in a later commit.

Developers will know what to choose from (answering the argument that there are "too many files"). The worst thing is to exclude important developer software/hardware, e.g., alpine docker containers, or raspberry pi (which I personally use to develop and run docker hosts).

Add it back! 😄