/cc @crwilcox, @busunkim96, @tswast

Follow-on to #7825. Because we are releasing new features in google-api-core and (more importantly) google-cloud-core, we need to handle this release phase delicately. Current clients which depend on google-cloud-core use a too-narrow pin:

$ grep google-cloud-core */setup.py | grep -v "^core"
bigquery/setup.py:    "google-cloud-core >= 0.29.0, < 0.30dev",
bigtable/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
datastore/setup.py:    'google-cloud-core >=0.29.0, <0.30dev',
dns/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
firestore/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
logging/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
resource_manager/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
runtimeconfig/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
spanner/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
storage/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',
trace/setup.py:    'google-cloud-core >=0.29.0, <0.30dev',
translate/setup.py:    'google-cloud-core >= 0.29.0, < 0.30dev',

Per conversation today, we plan to go ahead and release a 1.0.0 of google-cloud-core. Before that, we need to make releases from the last tags of the clients above which broaden the range to google-cloud-core >= 0.29.0, < 2.0dev.

Prep Releases

For each of the following:

• bigquery (BigQuery: Widen range for 'google-cloud-core'. #7969)
• bigtable (Bigtable: Widen range for 'google-cloud-core'. #7970)
• datastore (Datastore: Widen range for 'google-cloud-core'. #7971)
• dns (DNS: Widen range for 'google-cloud-core'. #7972)
• firestore (Firestore: Widen range for 'google-cloud-core'. #7973)
• logging (Logging: Widen range for 'google-cloud-core'. #7974)
• resource_manager (Resource Manager: Widen range for 'google-cloud-core'. #7975)
• runtimeconfig (Runtimeconfig: Widen range for 'google-cloud-core'. #7976)
• spanner (Spanner: Widen range for 'google-cloud-core'. #7977)
• storage (Storage: Widen range for 'google-cloud-core'. #7978)
• trace (Trace: Widen range for 'google-cloud-core'. #7979)
• translate (Translate: Widen range for 'google-cloud-core'. #7980)

the procedure is:

• Make a "release branch" from the last tag, e.g. $ git checkout -b bigquery-1.11-back bigquery-1.11.2.
• Push that branch to upstream, e.g. $ git push upstream bigquery-1.11-back.
• Make a branch from that branch, e.g. $ git checkout -b bigquery-1.11.3-release bigquery-1.11-back.
• Update the pin in setup.py to google-cloud-core >= 0.29.0, < 2.0dev.
• Commit the change, e.g. $ git commit setup.py -m "Widen range for 'google-cloud-core'."
• Push the -release branch, e.g. $ git push origin bigquery-1.11.3-release.
• Make a PR for the -release branch, targeting the -back branch.
• Label the PR autorelease-pending.
• Edit setup.py to bump the version, e.g. to 1.11.3.
• Edit CHANGELOG.md to include the widening and PR #.
• Push those changes to the origin branch.
• Merge the PR after CI.
• Update the local branch, e.g. $ git checkout bigquery-1.11-back && git fetch upstream && git merge upstream/bigquery-1.11-back.
• Tag the local branch, e.g. $ git tag bigquery-1.11.3
• Push the tag, e.g.: $ git push upstream bigquery-1.11.3.
• Monitor the PR to see that the bot updates the tags and makes / releases artifacts. Note: I had to do the release tagging / push to PyPI bits manually.

Core Releases

Once all the prep releases are finished, use releasetool to make new releases of core packages:

• api_core-1.11.0 (Release api_core 1.11.0 #7985)
• Update core/setup.py to pin google-api-core >= 1.11.0, < 2.0dev. (Core: update dep on 'api_core' >= 1.11.0. #7986)
• core-1.0.0 (Release core 1.0.0 #7990)

Update Client Library Pins

Once the new google-api-core and google-cloud-core releases are complete, create PRs for each client from master which bump the pins for each one accordingly to match:

• bigquery (Omnibus: pin new core 1.0.0 #7993)
• bigtable (Omnibus: pin new core 1.0.0 #7993)
• datastore (Omnibus: pin new core 1.0.0 #7993)
• dns (Omnibus: pin new core 1.0.0 #7993)
• error_reporting not needed, it doesn't directly depend on google-api-core / google-cloud-core
• firestore (Omnibus: pin new core 1.0.0 #7993)
• logging (Omnibus: pin new core 1.0.0 #7993)
• resource_manager (Omnibus: pin new core 1.0.0 #7993)
• runtimeconfig (Omnibus: pin new core 1.0.0 #7993)
• spanner (Omnibus: pin new core 1.0.0 #7993)
• storage (Omnibus: pin new core 1.0.0 #7993)
• trace (Omnibus: pin new core 1.0.0 #7993)
• translate (Omnibus: pin new core 1.0.0 #7993)

Client Library Releases

After merging the "update pins" PRs, run releasetool for each manual client, and shepherd out the releases:

• bigquery (Release bigquery 1.12.0 #8001)
• bigtable (Release bigtable 0.33.0 #8002)
• datastore does not yet have client_info support! See issue Datastore: add 'client_info' argument to client ctor. #8003.
• dns (Release dns 0.30.0 #8004)
• firestore (Release firestore 1.2.0 #8005)
• logging (Release logging 1.11.0 #8006)
• resource_manager (Release resource_manager 0.29.0 #8007)
• runtimeconfig (Release runtimeconfig 0.29.0 #8008)
• spanner (Release spanner 1.9.0 #8009)
• storage (Release storage 1.16.0 #8010)
• trace (Release trace 0.21.0 #8011)
• translate (Release translate 1.5.0 #8012)

Because error_reporting relies on transitive deps of google-cloud-logging to pick up new google-api-core and google-cloud-core versions, it has to be handled specially:

• Pin its dependency google-cloud-logging >= 1.11.0. (Error Reporting: pin 'google-cloud-logging >= 1.11.0'. #8015)
• Release it. (Release error_reporting 0.31.0 #8019)

Datastore:

• Actually implement the client_info feature. (Datastore: Add client_info support to client. #8013)
• Release it. (Release datastore 1.8.0 #8020)