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

chore(proto): reserved only for what would be breaking change #1684

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

joroshiba
Copy link
Member

@joroshiba joroshiba commented Oct 17, 2024

Summary

We have been using reserved to highlight gaps, but reserved should ideally only be utilized for reserving previously used identifiers.

Changes

  • removes reserved numbers that using were not actual breaking change
  • updates workflow to allow override and to always run all breaking checks even if previous fails

Breaking Changes

This has no real breaking changes, hence allowing override. The removal of the reserved makes it so that we don't have to do this in the future when adding new fields.

@github-actions github-actions bot added proto pertaining to the Astria Protobuf spec ci issues that are related to ci and github workflows labels Oct 17, 2024
Copy link
Member

@SuperFluffy SuperFluffy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are entering a new world - I think I'd remove all the reserved fields on the new v1 protobufs.

reserved 3 to 10;
reserved 15 to 20;
reserved 23 to 30;
reserved 57 to 60;

// deprecated fields
reserved 54; // deprecated "mint_action"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are effectively releasing new protobufs, are we justified in removing these fields as well?

reserved 3 to 10;
reserved 15 to 20;
reserved 23 to 30;
reserved 57 to 60;

// deprecated fields
reserved 54; // deprecated "mint_action"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one on the other hand I am fine with retaining, since this actually is the old v1alpha1 type.

Copy link
Contributor

@ethanoroshiba ethanoroshiba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Looks like the way the lint workflow is setup, the individual check may still fail but allow the overall status checks to pass, which I hope should be a good flag for anyone reviewing breaking proto changes in the future. Still, I think we may want to flag this to the broader engineering group as a "this label should probably almost never be used" thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
allow-breaking-proto ci issues that are related to ci and github workflows proto pertaining to the Astria Protobuf spec
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants