Bump major version to v29

[gmlewis]

Note to @willnorris - the only way I could figure out to get this to work (now with the inclusion of the scrape package) was to remove the go.mod and go.sum from the scrape directory. (Because v29 of go-github does not exist until the PR is committed and the repo is tagged.)

I'm thinking this makes the most sense anyway since the top-level go.mod covers the whole repo.

If you find a better mechanism, though, I'm totally happy to close this PR and go with the better solution.

[gmlewis]

Note to self: If this gets merged, then a release of this repo should be tagged with v29.0.0 before other PRs get merged.

[willnorris]

having a separate go.mod for the scrape package was very intentional (see #1308 (comment)). I likely won't be able to fully review this today, but do please wait to submit, as I'd like very much to keep the modules separate if at all possible.

/cc @dmitshur for comment and review as well

[willnorris]

what if you just leave the scrape package as relying on v28, and don't update that one in this change? Then, after this PR has landed and the new tag created, update the scrape package to use v29 in a separate change. Would that work?

[gmlewis]

Ah! OK. Sorry about that. I will fix it tonight and let you know when it is ready for review.
Thank you, Will!

[gmlewis]

Hi @willnorris - I believe this preserves the scrape versioning.

(I was a bit surprised that the dependencies of scrape are now being brought up into the top-level go.mod go.sum... and that they weren't before when scrape was first brought in. All I did to update go.mod go.sum was to run go test ./... and then all the scrape dependencies showed up... but I believe this is correct.)

PTAL.

[dmitshur]

I agree with Will’s comments. We must not remove the scrape/go.mod file as that would change module boundaries. It’s a good idea to keep this PR focused on just one module; updating the scrape module can be more safely done in later PRs.

Trying to make changes to more than one module (especially ones that are interconnected) in one PR is tricky and not worth doing until feeling very confident about the process.

Glenn, have you done go mod tidy in the latest version of this PR?

[gmlewis]

Thank you, @dmitshur!

Now I've run 'go mod tidy'. 😄

PTAL.

[dmitshur]

I don’t see any issues. One minor inline comment.

[dmitshur]

This change doesn’t look intentional.

I suspect it came about from the earlier version of this PR where the scrape/go.mod file was removed, and its requirements merged with that of the main go-github module. The scrape module happened to require a newer version of x/net:

go-github/scrape/go.mod

Line 10 in 04a52c2

golang.org/x/net v0.0.0-20191014212845-da9a3fd4c582

And so it stayed around after go mod tidy because this module also needs x/net.

It’s not harmful to keep it since it’s just a newer x/net, but it’s also probably better to make changes intentionally rather than due to chance.

You can go back to original or stay with the newer, I’m okay with both.

[gmlewis]

Ah, I see. Thank you, @dmitshur!
Reverted.

[gmlewis]

We discussed this PR in #1365. Should we merge master into this PR before merging or just move ahead as-is? - Edit: Sorry, this comment was confusing... I was thinking somehow that we were operating in different branches and not performing the squash and merge (which will bring all the recent changes under v29).

I would like to get approval from @willnorris on this PR since this is the first one containing scrape.

Thank you!

[willnorris]

yeah, I think this looks right and is consistent with what we discussed.

[gmlewis]

Thank you, @willnorris !
Merging.

[gmlewis]

Ugh... I broke the build. Trying to figure out how to roll this back.

[gmlewis]

#1367 should fix this release.