0 Members and 1 Guest are viewing this topic.
Quote from: bytemaster on October 02, 2014, 12:44:03 pmDon't upgrade to .19. Clearly it has issues. any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?
Don't upgrade to .19. Clearly it has issues.
Quote from: GaltReport on October 02, 2014, 01:07:32 pmQuote from: emski on October 02, 2014, 01:06:20 pmQuote from: GaltReport on October 02, 2014, 01:02:27 pmQuote from: wackou on October 02, 2014, 12:59:50 pmQuote from: bytemaster on October 02, 2014, 12:44:03 pmDon't upgrade to .19. Clearly it has issues. any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.All delegates should be on the same version. Unless we want forks.Can't they delay planned forks ? Not sure if that is what you are referring to or not. I only notice that when we do upgrades their are days when people are on different versions.Forks are hardcoded in the code for block number. Current v0.4.19 fork is scheduled for block 640000. All v0.4.19 will fork at that block. Any previous versions might not accept blocks produced by v0.4.19. That is why either all (most) of the delegates upgrade by block 640000 or none (very few) of them upgrade. Note that v0.4.19-RC1 is different version -> it should not accept blocks by both v0.4.19 and v0.4.18.
Quote from: emski on October 02, 2014, 01:06:20 pmQuote from: GaltReport on October 02, 2014, 01:02:27 pmQuote from: wackou on October 02, 2014, 12:59:50 pmQuote from: bytemaster on October 02, 2014, 12:44:03 pmDon't upgrade to .19. Clearly it has issues. any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.All delegates should be on the same version. Unless we want forks.Can't they delay planned forks ? Not sure if that is what you are referring to or not. I only notice that when we do upgrades their are days when people are on different versions.
Quote from: GaltReport on October 02, 2014, 01:02:27 pmQuote from: wackou on October 02, 2014, 12:59:50 pmQuote from: bytemaster on October 02, 2014, 12:44:03 pmDon't upgrade to .19. Clearly it has issues. any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.All delegates should be on the same version. Unless we want forks.
Quote from: wackou on October 02, 2014, 12:59:50 pmQuote from: bytemaster on October 02, 2014, 12:44:03 pmDon't upgrade to .19. Clearly it has issues. any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.
I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.
Quote from: bytemaster on October 02, 2014, 12:44:03 pmDon't upgrade to .19. Clearly it has issues. What if you already did and it's working?
network_set_advanced_node_parameters { "peer_connection_retry_timeout": 10, "desired_number_of_connections": 10, "maximum_number_of_connections": 10 }