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

[#605] Use more appropriate field names #709

Merged
merged 4 commits into from
Sep 1, 2017

Conversation

elliott-beach
Copy link
Contributor

This PR renames two fields as per discussion in #605:
Authorizations.UpdateAt => UpdatedAt
DeploymentStatus.UpdatedAt => PushedAt

As this is a breaking API change, would it be appropriate to merge these changes as a single version bump with #706, also a breaking change?

@elliott-beach elliott-beach changed the title Use more appropriate field names [#605] Use more appropriate field names Aug 30, 2017
@dmitshur
Copy link
Member

dmitshur commented Aug 30, 2017

As this is a breaking API change, would it be appropriate to merge these changes as a single version bump with #706, also a breaking change?

We can merge them soon one after another, but I don't think it should be a goal to unify unrelated breaking API changes just because they both break the API. In fact, it's better not to, because then people can upgrade one version at a time if they wish. Also, it makes reverting one of them easier, if necessary (not that reverting is likely to happen, but there's always a non-zero chance). They're separate and independent changes, let's treat them that way.

@@ -137,7 +137,7 @@ type DeploymentStatus struct {
Description *string `json:"description,omitempty"`
TargetURL *string `json:"target_url,omitempty"`
CreatedAt *Timestamp `json:"created_at,omitempty"`
UpdatedAt *Timestamp `json:"pushed_at,omitempty"`
PushedAt *Timestamp `json:"pushed_at,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

Now that I've looked, are we sure pushed_at is the right JSON field?

It doesn't look to be. I think it might be updated_at instead.

Take a look at https://developer.github.com/v3/repos/deployments/. There are 7 hits for "updated_at", 0 for "pushed_at".

Copy link
Member

@dmitshur dmitshur left a comment

Choose a reason for hiding this comment

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

You'll probably need to rebase this on top of latest master, then you can bump libraryVersion another time.

Otherwise LGTM.

@dmitshur dmitshur requested a review from gmlewis August 30, 2017 16:19
Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

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

LGTM after you bump the libraryVersion as requested by @shurcooL.
Thank you, @e-beach and @shurcooL!

@elliott-beach
Copy link
Contributor Author

@shurcooL This should be good-to-go now.

@dmitshur dmitshur merged commit 24139d5 into google:master Sep 1, 2017
@dmitshur
Copy link
Member

dmitshur commented Sep 1, 2017

Thanks again @e-beach.

nbareil pushed a commit to nbareil/go-github that referenced this pull request May 1, 2018
…ogle#709)

Authorization struct had a "updated_at" JSON key mapped to UpdateAt,
which was an oversight/typo. It has been renamed to UpdatedAt, like all
other similar fields.

Deployments and DeploymentStatus structs had incorrectly mapped their
UpdatedAt field to a non-existing "pushed_at" JSON key. That means
their values were never populated. This change fixes that.

Bump library version as this is a breaking change.

Helps google#605.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants