Skip to content

Conversation

michaellee1019
Copy link
Member

@michaellee1019 michaellee1019 commented Jan 24, 2025

Adds the current config of the fragment history entry to the GetFragmentHistory API. This is a simplified version of an old PR that I found: #578. As Emily P mentioned in that PR, trying to do all changes at once is going to cause a headache in app as well as SDKs. Lets deprecate and rename the existing fields later and get the main parts of the project done first.

@github-actions github-actions bot added the safe to test committer is a member of this org label Jan 24, 2025
@michaellee1019 michaellee1019 changed the title Update FragmentHistoryEntry for fragment versioning APP-7502: Update FragmentHistoryEntry for fragment versioning Jan 24, 2025
Copy link
Contributor

@Abalaxy Abalaxy left a comment

Choose a reason for hiding this comment

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

LGTM

Fragment old = 3 [(tagger.v1.tags) = "bson:\"old\" json:\"old\""];
AuthenticatorInfo edited_by = 4 [(tagger.v1.tags) = "bson:\"edited_by\" json:\"edited_by\""];
string revision = 5 [(tagger.v1.tags) = "bson:\"revision\" json:\"revision\""];
google.protobuf.Struct config = 6 [(tagger.v1.tags) = "bson:\"fragment\" json:\"fragment\""];
Copy link
Contributor

Choose a reason for hiding this comment

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

double checking, this field config will eventually replace old? also, should the bson tags be config as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops my bad about the tags, will update. Yes I think old will be deprecated. It doesn't make sense to drive the fragment version history off of old if we are storing that version's config as well. Plus its confusing to have the entire fragment in the response.

We have a lot of tasks to complete to migrate completely off of old and then we can deprecate it everywhere.

@michaellee1019 michaellee1019 added the ready-for-protos add this when you want protos to compile on every commit label Jan 24, 2025
@michaellee1019 michaellee1019 added the bug Something isn't working label Jan 24, 2025
@michaellee1019 michaellee1019 added ready-for-protos add this when you want protos to compile on every commit and removed bug Something isn't working protos-compiled ready-for-protos add this when you want protos to compile on every commit labels Jan 24, 2025
@michaellee1019 michaellee1019 removed the ready-for-protos add this when you want protos to compile on every commit label Jan 24, 2025
@michaellee1019 michaellee1019 merged commit 1b3c46b into main Jan 24, 2025
11 of 15 checks passed
@michaellee1019 michaellee1019 deleted the michaellee1019-patch-1 branch January 24, 2025 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

protos-compiled safe to test committer is a member of this org

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants