You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Fluffy has no release cycle. Also no binaries are provided, and a user is required to either build from source or use the latest docker image (https://hub.docker.com/r/statusim/nimbus-fluffy/tags), which also only exists for linux/amd64 and gets updated every night.
As we are working more towards a stable Portal history & beacon network, while further researching/developing the state network, it will soon become important to have a release cycle and to provide version tagged binaries / docker images.
The difficulty here will however be how we deal with branches in the nimbus-eth1 repository, now and in the future.
As long as nimbus EL client does not have a release cycle itself, I think we could get away with a general unstable and a stable-fluffy branch. However as soon as nimbus EL also requires a release cycle, adding even more branches will become complicated. And releasing projects at the same time (same branches) probably does not really make sense.
So it might be better to anticipate and move Fluffy already to a separate repository.
Then there is also the choice whether to move Fluffy completely or only the client part and keep the core Portal code here.
Separating Fluffy also makes sense for the hosting of the fluffy.guide in case there comes a nimbus EL guide.
And then there is basically the same question for the nimbus verified proxy, which could use its own little guide.
RFC on the separate repo structure or not...
The text was updated successfully, but these errors were encountered:
Currently Fluffy has no release cycle. Also no binaries are provided, and a user is required to either build from source or use the latest docker image (https://hub.docker.com/r/statusim/nimbus-fluffy/tags), which also only exists for linux/amd64 and gets updated every night.
As we are working more towards a stable Portal history & beacon network, while further researching/developing the state network, it will soon become important to have a release cycle and to provide version tagged binaries / docker images.
For this we can use same/similar procedure as is done for nimbus-eth2: https://github.com/status-im/nimbus-eth2/blob/stable/.github/workflows/release.yml
The difficulty here will however be how we deal with branches in the nimbus-eth1 repository, now and in the future.
As long as nimbus EL client does not have a release cycle itself, I think we could get away with a general
unstable
and astable-fluffy
branch. However as soon as nimbus EL also requires a release cycle, adding even more branches will become complicated. And releasing projects at the same time (same branches) probably does not really make sense.So it might be better to anticipate and move Fluffy already to a separate repository.
Then there is also the choice whether to move Fluffy completely or only the client part and keep the core Portal code here.
Separating Fluffy also makes sense for the hosting of the fluffy.guide in case there comes a nimbus EL guide.
And then there is basically the same question for the nimbus verified proxy, which could use its own little guide.
RFC on the separate repo structure or not...
The text was updated successfully, but these errors were encountered: