Update install instructions to use release 0.1.0 files

[trisberg]

Fixes #286

Proposed Changes

• Update install instructions to use files from the Serving 0.1.0 release instead of latest

[trisberg]

/assign @mattmoor

[samodell]

Curious about the rationale behind this change -- why is /latest/ no longer a good strategy? @trisberg

If we swap out latest for a specific version number, we'll need to update these commands regularly moving forward.

[trisberg]

@samodell it was suggested by @mattmoor and it seems to me that we need the instructions to point to a stable release. The latest aren't always completely stable and could give new users unexpected surprises. I agree that it's not ideal having to change the docs for every stable release and hope we can come up with a solution for this.

[mattmoor]

@samodell it's a function of stability and putting our best foot forward for newcomers.

We know these samples work with 0.1.0, but now we might make breaking changes (intentionally or not). I don't want prospective users to have a bad experience because of a bad nightly release the day before.

Does that make sense? WDYT?

[mattmoor]

/lgtm
/approve
/hold

Hold for discussion with @samodell. Thanks for jumping on this @trisberg.

[google-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mattmoor, trisberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [mattmoor]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[samodell]

Makes sense! Definitely agree we want to always direct users to stable versions. Would it be possible to have a "latest-stable" pointer similar to "latest" instead of hard-coding the versions? I don't know the complexity that might be involved, but if it's not a huge amount of work it might be worth it. @mattmoor

[mattmoor]

cc @adrcunha

I think the question is how we define "stable" :)

/hold cancel

[adrcunha]

We discussed that earlier this week. +1

[krancour]

latest and latest-stable are both bad, regardless of stability. Or more generally, "mutable tags" are bad-- for the simple reason that what you get when you ask for "latest" today vs what you get when you ask tomorrow could be completely different things. Even if they're both stable, the user may be in for some surprises, including, but not limited to, behavior not matching the docs they are reading. Being explicit about versions is never a bad thing.

[krancour]

And if it's perceived as a maintenance burden to update docs with each release... that can always be automated.

[rgregg]

Glad we're making this change.

/lgtm