-
Notifications
You must be signed in to change notification settings - Fork 144
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
make client classic first #1
Comments
Reiterating conversation from previous forum: Doing this will require a Major version change. (https://semver.org/) Eventually I want to decouple the program(s) from configuration defaults entirely. But I see the reasoning for this now (since the project is largely supported by ETC-first backers), and think that if there's a time to do it, this seems like an OK one. Noting also that we'll need to very careful with data directories... Geth doesn't behave consistently or very predictably when managing FS structure with regard to -- settings (eg ethereum/go-ethereum#19172).
We are already doing a major repository change. We are about to release a new client. Releasing 1.10.0 would be sufficient. (Minor version change) If we want to do some radical changes, let's not hesitate to do them now. Because later will not happen |
Can you provide your reasoning here?
Ditto... reasoning? |
READMe.md:change project name into core-geth
Wondering if this is still an issue I can help with? ( You could assign me if you want :) ) |
Hey, wow! thanks @cryptoasuka! At this point the question is primarily an API one. Changing default behavior is a BIG change, which makes me a little skittish on changing from one (inherited) opinion to another. My preference would actually be to remove the ETH default, leaving no default, forcing the user to use some |
Big +1 on no default behavior. As someone who runs a lot of core-geth nodes, I very much prefer changes that things break things immediately and loudly (like having no default chain) so that I'm never caught with something broken that I think works. |
+1 to getting burned on this |
This issue has becomee very annoying for me. #245 This resolves it, although obviously not in an ideal way. There has got to be an off-by-one somewhere that, when the chain get 'Rewind to 1', or somewhere in download->import, block #1 is attempted for ancient storage duplicitously. The code comments hopefully explain why its OK to ignore AppendAncient when the block is below the ancient water level. Date: 2020-12-11 10:45:45-06:00 Signed-off-by: meows <b5c6@protonmail.com>
any preferences on flag naming for ethereum mainnet? edit: faucet already uses 'foundation', will stick with this. |
update: staying inline with recent upstream additions, --mainnet will be used for ethereum mainnet. initial phase (no chain flag warn) has begun, see: #319 |
Migrated from: etclabscore/multi-geth-fork#153
Original author: @soc1c
renaming and releasing allows us for a breaking change we should consider:
The text was updated successfully, but these errors were encountered: