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

make client classic first #1

Open
meowsbits opened this issue Feb 19, 2020 · 8 comments
Open

make client classic first #1

meowsbits opened this issue Feb 19, 2020 · 8 comments

Comments

@meowsbits
Copy link
Member

meowsbits commented Feb 19, 2020

Migrated from: etclabscore/multi-geth-fork#153
Original author: @soc1c


renaming and releasing allows us for a breaking change we should consider:

  • default chain should be classic (i.e., running without any flags)
  • default testnet should be kotti (i.e., running --testnet)
@meowsbits
Copy link
Member Author

Reiterating conversation from previous forum:


@meowsbits:

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).


@soc1c:

Doing this will require a Major version change. (https://semver.org/)

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


@meowsbits
Copy link
Member Author

Releasing 1.10.0 would be sufficient. (Minor version change)

Can you provide your reasoning here?

Because later will not happen

Ditto... reasoning?

meowsbits referenced this issue in meowsbits/core-geth Feb 27, 2020
READMe.md:change project name into core-geth
@ghost
Copy link

ghost commented Jul 22, 2020

Wondering if this is still an issue I can help with? ( You could assign me if you want :) )

@meowsbits
Copy link
Member Author

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 --<chain> flag.

@jcvernaleo
Copy link
Contributor

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.

@meowsbits meowsbits mentioned this issue Aug 24, 2020
@BelfordZ
Copy link

BelfordZ commented Nov 2, 2020

+1 to getting burned on this

meowsbits added a commit that referenced this issue Dec 11, 2020
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>
@iquidus
Copy link
Contributor

iquidus commented Feb 12, 2021

any preferences on flag naming for ethereum mainnet? --ethereum or --foundation ?

edit: faucet already uses 'foundation', will stick with this.

@iquidus
Copy link
Contributor

iquidus commented Mar 25, 2021

update: staying inline with recent upstream additions, --mainnet will be used for ethereum mainnet.

initial phase (no chain flag warn) has begun, see: #319

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants