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

Document what constitutes a breaking change #1728

Closed
4 tasks
rigelrozanski opened this issue Jul 18, 2018 · 7 comments · Fixed by #6394
Closed
4 tasks

Document what constitutes a breaking change #1728

rigelrozanski opened this issue Jul 18, 2018 · 7 comments · Fixed by #6394
Labels
T:Docs Changes and features related to documentation.

Comments

@rigelrozanski
Copy link
Contributor

Maybe to be in the contributing guidelines? or at least linked from the contributing guidelines, and add somewhere else

"I’ve also been thinking about this a bunch.. not sure if a change would cause one to run transactions differently it would also be breaking? couldn’t replay blocks the same way/ in a bad scenario would prevent consensus. Let’s explicitly document what a breaking change is"

"is our definition of "non-breaking" only related to state modifications?"

CC @cwgoes @ebuchman


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@rigelrozanski rigelrozanski added the T:Docs Changes and features related to documentation. label Jul 18, 2018
@ValarDragon
Copy link
Contributor

I think anything that would cause a tx, or abci header, to modify state differently is a breaking change, in addition to just plain changing the structure of stores.

@rigelrozanski
Copy link
Contributor Author

Interesting I feel like there are different levels of how breaking a change can be - like some changes might be breaking in that they introduce a new transaction type however it doesn't interfere with how historical transactions have been run and therefor it wouldn't break a testnet if you were to just start running software with this new change (you might just halt consensus if 50% of folks upgraded)

@cwgoes
Copy link
Contributor

cwgoes commented Jul 18, 2018

I think "inclusive state machine breaking" is a reasonable definition for now - a non-breaking change must successfully process all transactions that would have been successfully processed before the change. It can additionally successfully process transactions that would not have been successfully processed before.

@ebuchman ebuchman self-assigned this Jul 18, 2018
@alexanderbez
Copy link
Contributor

The definition @cwgoes pointed out makes intuitive sense. I think it'll still be beneficial if we could also point out/tag non-breaking changes that do break client facing APIs.

Also, since discussion has started on this, I'll move it to the "In Progress" lane.

@cwgoes
Copy link
Contributor

cwgoes commented Jul 18, 2018

This should be defined in #790.

@tac0turtle
Copy link
Member

@alessio do you want to include this in your PR about releases? it goes hand in hand

@alessio
Copy link
Contributor

alessio commented Jul 3, 2020

Oh wow, is it #throwbackFriday today 😄? Thanks @marbar3778, I'll incorporate this in my PR

alessio pushed a commit that referenced this issue Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T:Docs Changes and features related to documentation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants