CometBFT v1.0 release plan: cometbft/cometbft#578
(looks nearly complete, down to tagging modules, but who knows)

Back to draft now that CI ran once. (pass 🥳 )

Hey,

Happy to comment on some of these. You are one of the first teams to experiment with upgrading to v1 so really appreciate the questions and thoughts here as they enable us to know what is important vs. unimportant.

timeout_prevote and timeout_commit are consolidate to timeout_vote. Surely this is a consensus breaker.

Actually this is not consensus breaking. (Ref) What is important is that validators/node operators coordinate and aware of the configuration change and maintain the configuration of timeout_vote consistent. But this change is not encoded does not affect content of blocks or hashes, so it is not consensus breaking.

Their GenesisDoc type no longer has a ABCI field, and now has a Synchrony and Feature field

Largely due to introduction of PBTS. Ref: https://informal.systems/blog/introducing-proposer-based-timestamps-pbts-in-cometbft

why have these things changed, what is the motivation?
what else may have changed?
how the heck can you upgrade smoothly without consensus breaking

The changelog should be comprehensive. I understand the feedback and feeling here is that too many things changed; is it less disruptive and more useful for you to have smaller, more frequent releases?

Actually if you do not enable PBTS I believe nothing in v1 is consensus breaking. I will double check this but your validators might not even need to coordinate in rolling out the upgrade - the proto changes might require coordination (let me confirm though). This is because the block protocol remains unchanged fundamentally in v1.

Separate topic: Here is a basic reference we have w.r.t upgrade taxonomy.

Glad to explain further or in a call if useful.

@adizere Thanks! Sorry for the delay in responding -- you commented while I was on break.
I will review and get back to you ASAP. We will certainly appreciate any guidance that comes from cometbft/cometbft#3416

@adizere Hey, I tried rolling updates to comet1.0 build, here are my first set of observations:

• Good news, No consensus breakage with a rolling upgrades. Tested with both scenarios with super majority of nodes in the new and old versions.
• P2P panics:
  nodes on older versions panic as they receive messages from the nodes on newer versions, potentially due to the changes in this PR which introduces this new message (HasProposalBlockPartMessage). The panic closes the connection to the peer and reestablish it, and I observe tis behavior with every block.

• Is panic necessary here? can the protocol be changed to ignore these messages and not cause the old nodes to panic?

• What are the consequences of not consuming these HasProposalBlockPartMessage messages? Are there any liveness issues? I have not noticed any, but want to confirm. Also, will this force us to do a coordinated upgrades among the validators?

Node with older versions: Panicking

Peer disconnects with every block:

• Logging issues:
  There are lots of noise from the mempool, which I don't think is necessary. Below are the screenshots
  
  This is one other log message I used to observe a lot while doing stress test and even on smaller loads. But I haven't observed this anymore on comet1.0, looks like u guys fixed it. But I want to bring it up.
  

Indexer works as expected with both versioned and non versioned endpoints.