search

platformsh / legacy-cli

This is the legacy version of Platform.sh's command-line interface. The new version is at: https://github.com/platformsh/cli
https://docs.platform.sh/administration/cli.html
MIT License
221 stars 120 forks source link

Check for new CLI versions on command run #339

Closed budda closed 8 years ago

budda commented 9 years ago

A lot of popular CLI tools these days report if a newer version of the tool is available when a command is executed.

It would be nice to implement a reminder to upgrade the Platform CLI tool if the current version is old.

pjcdawkins commented 9 years ago

Agreed - this should be possible after a move to a new install method (see https://github.com/platformsh/platformsh-cli/pull/338)

pjcdawkins commented 9 years ago

A vague plan:

  1. Write a timestamp in the phar to show when it was built (Composer does this) [see below for ralt's note on this]
  2. Also, write a timestamp to a file to show when we have last checked for updates, e.g. in something like ~/.platformsh/cli.conf.yaml
  3. If (phar age > 7 days) and (not already checked in the last day), check for a new version, and offer to update
  4. Allow switching off automatic updates altogether via config (again, ~/.platformsh/cli.conf.yaml), and perhaps via a command
ralt commented 9 years ago

For 1., please make it based on a timestamp stored in a file, such as the changelog. Writing a timestamp based on the build time prevents any kind of reproducible build.

pjcdawkins commented 9 years ago

Agreed... this could even allow the version's date to be reported in platform --version.

And yes I should probably be committing a changelog too.

ralt commented 9 years ago
  1. and 2. seem redundant, don't they? Just write a timestamp if no timestamp exists (so, it will be the 1st time platform is run)

Or maybe not, since it would let you know if you installed then started running platform a month later. But it would let you have less code... not sure.

pjcdawkins commented 9 years ago

I was thinking the two-pronged approach would avoid the annoyance (e.g. from Composer) of warning the user frequently, and avoid the performance impact of checking for updates frequently. And this gives that minor advantage I just mentioned of seeing the version time in platform --version. There is no regularity in release dates and this lets us keep it that way.

ralt commented 9 years ago

I didn't mean to remove 2 completely, just to remove 1. So you wouldn't have the annoyance, since the check would still happen once a day. Just that the first timestamp wouldn't be the last changelog entry's, but the first time platform was run.

On Wed, Sep 9, 2015 at 10:33 PM, Patrick Dawkins notifications@github.com wrote:

I was thinking the two-pronged approach would avoid the annoyance (e.g. from Composer) of warning the user frequently, and avoid the performance impact of checking for updates frequently.

— Reply to this email directly or view it on GitHub https://github.com/platformsh/platformsh-cli/issues/339#issuecomment-139037756 .

Florian Margaine

pjcdawkins commented 8 years ago

Added in v2.8.1